Live data from Hacker News

The DROWN Attack

drownattack.com

91–100 of 206 posts

Re: The DROWN Attack

#91
post #60

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

Oh, I agree. I don't mean that the weakness created the vulnerability entirely, thank you for clarifying. I appreciate the excellent research and security investigation done here. It was excellently articulated and presented, and we need to keep improving our publicly available tools and finding these issues.

What I mean is that, today, many many years since the creation of the suite, the single-target cost has dropped to 'only' $440 per target for non-weakened ciphers. I love the money-to-execute-attack metric.

That's still high enough to slow down the viability of broad attacks for most attackers. What about in the past? How much was that back when the suite was created? Much higher. How much sooner did the weakened version make the attack efficient?

I don't mean that the government is the source of all crypto flaws, I mean that we have a specific example of a government mandated crypto 'back door' weakness causing a specific harm, making exploitation of a security flaw substantially easier. This is direct evidence of the harm caused by undermining security, which the government is currently adamant can be done "safely". The security and hacker communities know that this is not true, and this is a timely counter-factual example.

This is direct evidence that weakening cryptography, including back-doors, and special "one time" access fundamentally cause harm by undermining the security of cryptography for everyone.

Re: The DROWN Attack

#92
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…

> RSA is obsolete. Stop using it. The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?). Neither Curve25519 nor Curve448 - which are said to be s…

> The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe.

I don't believe this is accurate. It is true that there are complaints about the curves' design in parameter transparency and their difficulty to implement them securely. But I don't think people are actually suggesting the curves are not safe to use conceptually.

P-256 facilitated ECDSA should be good to use until the new curves are adopted (which will take a while) as long as you're not writing implementations yourself. It is true that the new curves will be a better alternative once they are available given that they are designed for transparency and ease of implementation.

Re: The DROWN Attack

#93

Earlier quoted context omitted.

> RSA is obsolete. Stop using it. The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?). Neither Curve25519 nor Curve448 - which are said to be s…

You have two choices then: - Use RSA until 25519/448 land in TLS - Switch to ECDSA in the interim Personally, I would switch even though ECDSA isn't great. The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible. You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy. EDIT: I use secp384r1 f…

The NIST curves also have constants which may or may not be manipulated.

Bruce Schneier recommends against using them.

Re: The DROWN Attack

#94
post #93

Earlier quoted context omitted.

You have two choices then: - Use RSA until 25519/448 land in TLS - Switch to ECDSA in the interim Personally, I would switch even though ECDSA isn't great. The concerns over P-256 and P-384 are more academic than anything: They're hard to implement safely and without side-channels. Read: hard, not impossible. You shouldn't be writing your own ECDSA implementation, however. That'd be foolhardy. EDIT: I use secp384r1 f…

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

I would recommend against using them if your adversary is the NSA and your threat model comes wrapped in tin foil (and if I didn't, I'd get ignored anyway).

If so, use NaCl/libsodium at the application layer and don't rely on ECDSA alone.

If your threat model is "criminals", ECDSA is less insane than RSA (provided, once again, you're not implementing it yourself, you're relying on developed by a team of cryptographers and security engineers).

Re: The DROWN Attack

#95
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…

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, if we can't get rid of export ciphersuites after twenty years, what is the probability that we'll manage to get rid of RSA in just a few? I'm not that optimistic.

There would be very little problem with RSA in TLS if people had moved to modern schemes like OAEP and RSA-PSS. The problem is that we didn't, and we're stuck with obsolete crap. Moving away from obsolete crap isn't the solution, it's the definition of the problem.

Re: The DROWN Attack

#96
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…

RSA isn't obsolete. PKCS1v1.5 padding is obsolete.

I'm with you on this one. This 'RSA is evil' conclusion is like taking a look at [1]---or the gazillion Schnorr-style signature scheme nonce leaks published over the years---and concluding that elliptic curves are evil.

[1] http://web-in-security.blogspot.com/2015/09/practical-invali...

Re: The DROWN Attack

#98

Earlier quoted context omitted.

> RSA is obsolete. Stop using it. The problem is, the ONLY curves that are supported in practice are NIST P-256 (prime256v1) and P-384 (secp384r1), which aren't considered safe. So, I guess, many are reluctant to switch (because we're non-experts and don't know real implications, but we heard that there's something not right there - and shouldn't one be wary?). Neither Curve25519 nor Curve448 - which are said to be s…

Frankly I don't do security critical things on TLS anymore. I'm tired of having to wait in limbo for months to fix known vulnerabilities.

Other protocols are probably just as broken, we just haven't found the vulnerabilities yet. Few protocols (if any) get as much scrutiny as SSL/TLS.

Re: The DROWN Attack

#99
post #85
post #58

Earlier quoted context omitted.

> But Heartbleed was the first one Perhaps with a logo - I never really pay much attention to logos - but it wasn't the first to have an accessible name. Just off the top of my head I can name 3 SSL vulnerabilities that predated Heartbleed: BEAST, CRIME, BREACH. Personally I can't see how having a logo changes much in terms of press coverage since radio and printed newspapers tend not to publish the logos, online pub…

And if we step outside SSL vulnerabilities: - ILOVEYOU - Melissa - Slammer We've been naming attacks for a long time. Perhaps one difference is that these days, a vulnerability is named if it's deemed high-risk/high-impact. In the past, vulnerabilities became well-known names once they'd been seen to do serious damage.

Let's not forget the Millennium bug. That thing also had a logo: http://ichef.bbci.co.uk/news/304/media/images/79938000/jpg/_...

Re: The DROWN Attack

#100

Earlier quoted context omitted.

Frankly I don't do security critical things on TLS anymore. I'm tired of having to wait in limbo for months to fix known vulnerabilities.

What do you use instead? SSH? IPSec?

Go to datacenter. Open cage. Plug in keyboard. Oldschool.
Post reply on HN