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

151–160 of 206 posts

Re: The DROWN Attack

#151

Post by DenisM »

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 that:

Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?

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?

Re: The DROWN Attack

#152

Post by stock_toaster »

tptacek wrote: post #109
_yy wrote: post #93

Earlier quoted context omitted.

The NIST curves also have constants which may or may not be manipulated. Bruce Schneier recommends against using them.

Even Bernstein doesn't argue that the NIST curve seeds are actually backdoors. Schneier isn't a curve researcher; in fact, he's more like an anti-curve pundit. I'm not sure his opinion is all that powerful. Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.

What about the NSA "freaking out"[1] about ECC in general?

[1]: http://blog.cryptographyengineering.com/2015/10/a-riddle-wra...

Re: The DROWN Attack

#153

Post by Gibbon1 »

Nimi wrote: post #145
matthewdgreen wrote: post #95

Earlier quoted context omitted.

The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made good progress shifting towards DH/ECDH ciphersuites -- and TLS v1.3 will eliminate RSA entirely -- we have essentially no deployment of DSA/ECDSA certificates. It's all RSA. So "getting rid of RSA" sounds good, but won't happen in TLS/SSL anytime soon. Moreover,…

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 is to create some sort of license where once the sunset deadline is established, the license to use it expires hard on the deadline.

Re: The DROWN Attack

#154

Post by tptacek »

stock_toaster wrote: post #152
tptacek wrote: post #109

Earlier quoted context omitted.

Even Bernstein doesn't argue that the NIST curve seeds are actually backdoors. Schneier isn't a curve researcher; in fact, he's more like an anti-curve pundit. I'm not sure his opinion is all that powerful. Regardless, I'm not suggesting new cryptosystems should use the NIST P-curves. They shouldn't; those curves are just as tricky to use as RSA.

What about the NSA "freaking out"[1] about ECC in general? [1]: http://blog.cryptographyengineering.com/2015/10/a-riddle-wra...

Rodents of unusual size? I don't think they exist.

Re: The DROWN Attack

#155

Post by wolf550e »

AnimalMuppet wrote: post #131
tptacek wrote: post #111

Earlier quoted context omitted.

Use Curve25519.

drdaeman says that Curve25519 isn't usable with X.509 and TLS. Your reply is "Use Curve25519". What are you saying? That drdaeman is wrong, and Curve25519 can be used with TLS? Or are you saying, "don't use TLS"? Or... what?

The spec for Ed25519 signatures in TLS is not yet ready: https://tools.ietf.org/html/draft-irtf-cfrg-eddsa-02

X25519 for key exchange in TLS is ready and is in openssl master (and in boringSSL). I don't know the status of NSS support, or plans for SChannel and CoreCrypto support.

X25519 key exchange and Ed25519 signatures have been deployed in nacl, libsodium, ssh, etc. for a while.

EDIT: NSS ticket for X25519 Key Exchange: https://bugzilla.mozilla.org/show_bug.cgi?id=957105

Re: The DROWN Attack

#156

Post by dadrian »

tptacek wrote: post #104
matthewdgreen wrote: post #95

Earlier quoted context omitted.

The problem is that RSA is also used for most certificates, including signing certificates. This attack also implicates digital signatures. While we've made good progress shifting towards DH/ECDH ciphersuites -- and TLS v1.3 will eliminate RSA entirely -- we have essentially no deployment of DSA/ECDSA certificates. It's all RSA. So "getting rid of RSA" sounds good, but won't happen in TLS/SSL anytime soon. Moreover,…

RSA OAEP and PSS is just as unlikely to win the Internet as ECDH and curve signatures. But if you had to pick one to win, you'd pick curves.

Why argue about which battle to fight, and try to do both? Get widespread support for ECDSA; get RSA implementations up to date with modern padding schemes. We don't need to pick and choose which modern crypto to use; use modern crypto everywhere.

Obviously upgrading old clients is hard, but that's going to be a problem regardless. So in new standards that need RSA (e.g. something where the private key needs to be able to encrypt and sign), push for OEAP. If they don't need RSA, push for modern curves.

Re: The DROWN Attack

#157

Post by bmurphy1976 »

rmc wrote: post #29
bencollier49 wrote: post #3

These marketed attacks with special logos drive me up the wall. If I ever discover one I'll give it a rude name and force everyone to look at a silly picture to go with it.

But Heartbleed was the first one, and it's marketing made it get everywhere. Regular newspapers, etc. Instead of hating people marketing vulnerbilities, tackle why people-in-power don't care about vuln when communicated the old way.

> But Heartbleed was the first one, and it's marketing made it get everywhere. Regular newspapers, etc.

This is a blip. As soon as this escalates and everybody starts "Marketing" their latest security vulnerabilities they will once again be lost in the storm.

Re: The DROWN Attack

#158

Post by pekk »

It would be fine if this were just a public service announcement, but then there is the huge political rant at the bottom. The use of a vulnerability as a megaphone for personal opinions is very annoying.

Re: The DROWN Attack

#159

Post by pekk »

tamana wrote: post #97

Why does everyone bug need its own domain name?

If you look at the bottom of the page, you will see that some of the underlying motivation for the site is to shill for a particular political stance.

Re: The DROWN Attack

#160

Post by tptacek »

dadrian wrote: post #156
tptacek wrote: post #104

Earlier quoted context omitted.

RSA OAEP and PSS is just as unlikely to win the Internet as ECDH and curve signatures. But if you had to pick one to win, you'd pick curves.

Why argue about which battle to fight, and try to do both? Get widespread support for ECDSA; get RSA implementations up to date with modern padding schemes. We don't need to pick and choose which modern crypto to use; use modern crypto everywhere . Obviously upgrading old clients is hard, but that's going to be a problem regardless. So in new standards that need RSA (e.g. something where the private key needs to be a…

Because even if you use OAEP, RSA is more error-prone --- particularly at a design level --- than curve cryptosystems and, for most applications, doesn't allow you to express anything you couldn't express better with curves.
Post reply on HN