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

171–180 of 206 posts

Re: The DROWN Attack

#171

Post by mcpherrinm »

DenisM wrote: post #151
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…

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

Note that there's an SSLv3 after SSLv2 -- both are broken, but SSLv2 is just a much bigger liability than before. SSLv3 is also broken.

You shouldn't have had SSLv2 enabled for many years now. If you need SSLv3 for WinXP support, this bug doesn't change anything in that regard.

Re: The DROWN Attack

#172

Post by DenisM »

pfg wrote: post #162
DenisM wrote: post #151

Earlier quoted context omitted.

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right? No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2. > Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right? I…

It does support TLS, but it's disabled out of the box, and no one who is still running XP is likely to turn it on.

Re: The DROWN Attack

#173

Post by DenisM »

pfg wrote: post #162
DenisM wrote: post #151

Earlier quoted context omitted.

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right? No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2. > Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right? I…

Ah so it's not exfiltratimg the key, it uses sslv2 oracle to break captured TLS traffic.

Ok, that makes it a lot less scary. Pretty bad still, but least the keys are not compromised.

Re: The DROWN Attack

#174

Post by pfg »

DenisM wrote: post #172
pfg wrote: post #162

Earlier quoted context omitted.

> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right? No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2. > Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right? I…

It does support TLS, but it's disabled out of the box, and no one who is still running XP is likely to turn it on.

That seems to be the case only for IE 6, not 7 or 8[1] (which are available on XP).

[1]: https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...

Re: The DROWN Attack

#175

Post by pfg »

syncsynchalt wrote: post #163
skywhopper wrote: post #19

So, disable SSLv2. That is not new information. I like how the FAQ insists you are still at risk if you've disabled SSLv2 because you still might be using it somewhere else!!! In other words, if you've not disabled SSLv2 everywhere, then there are still places where SSLv2 is enabled. Thank you.

Also, disabling SSLv2 in versions of openssl up til January did not actually disable SSLv2.

Or, more specifically, disabling all SSLv2 ciphers didn't disable SSLv2 entirely. Disabling SSLv2 as a protocol worked.

Re: The DROWN Attack

#176

Post by DenisM »

mcpherrinm wrote: post #171
DenisM wrote: post #151

Earlier quoted context omitted.

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

Note that there's an SSLv3 after SSLv2 -- both are broken, but SSLv2 is just a much bigger liability than before. SSLv3 is also broken. You shouldn't have had SSLv2 enabled for many years now. If you need SSLv3 for WinXP support, this bug doesn't change anything in that regard.

Good point on v3.

I kept v2 running because we couldn't bring ourselves to prevent connections from clients of our clients, it's not our place to tell them what to do, especially if it only harms them and no one else. This time it harms everyone, including high-privilege users, so it's a lot easier to justify.

Re: The DROWN Attack

#177

Post by DenisM »

pfg wrote: post #174
DenisM wrote: post #172

Earlier quoted context omitted.

It does support TLS, but it's disabled out of the box, and no one who is still running XP is likely to turn it on.

That seems to be the case only for IE 6, not 7 or 8[1] (which are available on XP). [1]: https://en.wikipedia.org/wiki/Template:TLS/SSL_support_histo...

Thanks for rescuing me from my own ignorance! I was reading a different chart that wasn't as clear.

Re: The DROWN Attack

#178

Post by dadrian »

tptacek wrote: post #60
ColinDabritz wrote: post #48

From the article: "For the third time in a year, a major Internet security vulnerability has resulted from the way cryptography was weakened by U.S. government policies that restricted exporting strong cryptography until the late 1990s." The bearing of this on the ongoing "backdoor" and "just one device" discussions is critical. This is direct evidence of real harm done by weakening encryption.

The attack is viable without export ciphers. The real issue here is the continued and unabated prevalence of PKCS#1 v1.5 padding (really, of RSA in general).

The MITM attack is only viable due to a bug introduced by handling of export ciphers, even though it affects non-export ciphers. So export ciphers are the real issue here.

Re: The DROWN Attack

#179

Post by dopamean »

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…

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 understand.

I often feel this way when security topics come up on HN. I've been writing code a long time and I think I'm of moderate intelligence and I often have no idea what anyone is talking about. I try not to lose sleep over it because I understand that security can be really, really complicated (even if the issue is "easy to explain") and so I'm just not going to get it.

Re: The DROWN Attack

#180

Post by Nimi »

Gibbon1 wrote: post #153
Nimi wrote: post #145

Earlier quoted context omitted.

Moving away from obsolete crap isn't the solution, it's the definition of the problem. One could argue that the CA/Browser forum has achieved some success with moving away from SHA-1. As a spectator, I don't understand why this process is not repeated for similar obsolete primitives or standards.

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?
Post reply on HN