Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The DROWN Attack

drownattack.com

Post reply on HN
Print view View original

181–190 of 206 posts

Re: The DROWN Attack

#181

Post by malka »

ColinDabritz wrote: post #132
themodelplumber wrote: post #116

Earlier quoted context omitted.

> The vulnerability here is tricky to exploit but actually simple to describe. Yessss finally > There's a padding oracle hysterical sobbing sounds

I ran across a related issue working on a project that I think helped me understand the broader issue better. I'll relate it here and see if it helps. We had user search functionality for an internal business application. We allowed searching by several fields, such as name, and phone number, and allowed partial matches, where the first part of a field matched. Phone numbers were restricted information for some users…

This is a really good explanation. Thanks you.

Re: The DROWN Attack

#182

Post by tptacek »

dopamean wrote: post #179
tptacek wrote: post #129

Earlier quoted context omitted.

An "oracle" is simply an circumstance in which an adversary can coerce you to use your secret key to do a useful computation, some result of which is revealed. Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error." Think of error oracles t…

This is a great explanation and I appreciate you providing it. I think the point GP was making was that he got literally 4 words into the "simple to explain" explanation before realizing this explanation is going to be like tons of other things he reads here and elsewhere that require so much prior and specialized knowledge as to be nearly impossible for someone lacking a high level of experience in the area to under…

Right. Well, you're not going to get the exploit from a simple description of the attack. DROWN is built on some well-known attacks on RSA, most notably Bleichenbacher's 1998 padding oracle attack, but the specifics of how to manipulate an RSA ciphertext to make TLS records intelligible to SSLv2 are hairy even if you've implemented BB98 before --- I'm going to call this "stunt Bleichenbachering".

So it's not very important that you understand exactly how to go from "errors/exceptions generated by the target" to "recovery of plaintext". Even if you understand the specifics of those kinds of attacks, they're even more complicated (and fun) here.

The interesting nut of the attack is: there's a well-known error oracle in both TLS and SSLv2, but it's long since been mitigated in both protocols. However, details of the crappy crypto in SSLv2 conspire to make the mitigation for padding oracles in SSLv2 ineffective, and you can use the SSLv2 oracle to attack TLS ciphertexts if TLS and SSLv2 ever share keys.

Re: The DROWN Attack

#183

Post by pmcao »

Is there anyone developing an exploit for this attack? You'll need a vulnerable openssl version to test. After major Linux distros releasing the path, it'll be difficult to obtain the vulnerable openssl.

Timemachine (debian) is a tool that constructs a Docker image of a Debian base system. You can choose a Debian distribution and a date in the past. Then install any (vulnerable) package of your choice for experiment. https://github.com/CSLDepend/timemachine

This tool is a part of a security testbed that we are developing. We have created container images of recent attacks in our repo, e.g., https://github.com/CSLDepend/itestbed/tree/master/repo/mitm/...

If anyone is interested in developing such testbed for reproducible security experiments, let me know @pmcao

Re: The DROWN Attack

#184

Post by skybrian »

tptacek wrote: post #129
themodelplumber wrote: post #116

Earlier quoted context omitted.

> The vulnerability here is tricky to exploit but actually simple to describe. Yessss finally > There's a padding oracle hysterical sobbing sounds

An "oracle" is simply an circumstance in which an adversary can coerce you to use your secret key to do a useful computation, some result of which is revealed. Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error." Think of error oracles t…

Are error oracles why security software nearly always has poor error messages and therefore poor usability? Or is that just tradition?

Re: The DROWN Attack

#185

Post by baby »

tptacek wrote: post #67

The vulnerability here is tricky to exploit but actually simple to describe. There's a padding oracle in the form of RSA used by both TLS and SSLv2; by repeatedly sending permuted versions of a ciphertext to an SSLv2 server, you can gradually discover the plaintext†. Both SSLv2 and TLS have countermeasures for this attack. But SSLv2's countermeasures are sabotaged by the crappy ciphers it also supports. In both TLS a…

And the rotation modulo after that to do a lattice attack \o/

Re: The DROWN Attack

#186

Post by tptacek »

skybrian wrote: post #184
tptacek wrote: post #129

Earlier quoted context omitted.

An "oracle" is simply an circumstance in which an adversary can coerce you to use your secret key to do a useful computation, some result of which is revealed. Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error." Think of error oracles t…

Are error oracles why security software nearly always has poor error messages and therefore poor usability? Or is that just tradition?

No, that's just tradition. Error oracles are a crypto thing; the errors don't even need to be exposed to users for them to be a problem (for instance, the Lucky13 TLS attack uses timing to discern exceptions, not actual error messages).

Re: The DROWN Attack

#187

Post by tptacek »

devit wrote: post #62

From the paper: "In order to decrypt one TLS session, the attacker must passively capture about 1,000 TLS sessions using RSA key exchange, make 40,000 SSLv2 connections to the victim server and perform 2^50 symmetric encryption operations" In other words, while this compromises TLS when SSLv2 is enabled, it seems to be only maybe practical for targeted use by state actors, and even then easily detectable by network c…

If by "state actors" you mean "people who can afford $500 of AWS compute", then yes.

Re: The DROWN Attack

#188

Post by Natanael_L »

Nimi wrote: post #180
Gibbon1 wrote: post #153

Earlier quoted context omitted.

I read an blog post by a guy with a long experience with this. What happens is large players demand that there be a 'reasonable' deadline for compliance. And then half the companies involved sit on their hands for two and a half years and then demand an extension. And then another and next thing you know you're still using RSA fifteen years after people knew they needed to stop using it. Only solution I can think of…

That's very interesting, do you happen to have a link for the blog post?

Probably this https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...

Re: The DROWN Attack

#189

Post by pbsd »

tptacek wrote: post #126
davidamarquis wrote: post #123

Earlier quoted context omitted.

What are the arguments against RSA OAEP?

Public key encryption transforms are one of the biggest foot-guns in cryptography. OAEP is at least not prima facie broken, but using it still exposes you to the the design risks of building with public key encryption. (There are attacks against OAEP, but they're less common and not intrinsic to the design the way PKCS1v15's are).

Even if RSA does go away, and it will, public-key encryption primitives won't. The post-quantum craze is mostly made up of encryption and signature primitives, so we have that to look forward to. Even the lattice-based key agreement we have is basically fancy KEM, which leads to things like [1].

My impression is that RSA never really got the "djb treatment". The people designing OAEP and friends were mostly theorists concerned with security reductions, not implementation issues. I think an idiot-proof RSA scheme could be devised, but it is now way too late for that.

[1] https://eprint.iacr.org/2016/085

Re: The DROWN Attack

#190

Post by Gibbon1 »

Natanael_L wrote: post #188
Nimi wrote: post #180

Earlier quoted context omitted.

That's very interesting, do you happen to have a link for the blog post?

Probably this https://medium.com/@sleevi_/a-history-of-hard-choices-c1e1cc...

Thanks that would be the one. I get this feeling that encryption protocols and standards often end up and all sorts of dank corners of the web infrastructure and finding and updating all of these is really messy task. And I suspect service providers and their customers haven't been really good at keeping track of everything.
Post reply on HN