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

81–90 of 206 posts

Re: The DROWN Attack

#81

Post by microcolonel »

drdaeman wrote: post #78
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…

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

Re: The DROWN Attack

#82

Post by CiPHPerCoder »

drdaeman wrote: post #78
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…

> 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 for signing random_compat, so if anyone gets bit by this recommendation, I will too: https://github.com/paragonie/random_compat/blob/master/dist/...

Re: The DROWN Attack

#83

Post by drdaeman »

aidenn0 wrote: post #80
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…

Having had to briefly use an old PalmOS phone when my previous phone died, I can say that very few HTTPS sites still support SSLv2. However, most imap/pop servers seem to still support it.

This. I've typed in one of my domain names and found out my Postfix had SSLv2 for some odd reason. No idea why, I always assumed the defaults had SSLv2 properly disabled. Wrote explicit `smtpd_tls_protocols = TLSv1, TLSv1.1, TLSv1.2, !SSLv2, !SSLv3`, reloaded the daemon, ran ` openssl s_client -connect localhost:25 -starttls smtp -ssl2`, saw the negotiation failure, hope I'm good now.

Re: The DROWN Attack

#84

Post by wolf550e »

jvehent wrote: post #68
tptacek wrote: post #57

Earlier quoted context omitted.

It's not enough to not run SSLv2 on the target; SSLv2 can't be available on any server that shares the same RSA keypair. It's a cross protocol attack, where attackers use the SSLv2 server as a tool to attack the TLS server.

Yes, as long as one of the server that shares the keypair has SSLv2 enabled.

has SSLv2 enabled or has CVE-2015-3197 and accepts SSLv2 cipher suites even with SSLv2 disabled.

Re: The DROWN Attack

#85

Post by manarth »

laumars wrote: post #58
rmc wrote: post #29

Earlier quoted context omitted.

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

Re: The DROWN Attack

#86

Post by wolf550e »

microcolonel wrote: post #81
drdaeman wrote: post #78

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.

What do you use instead? SSH? IPSec?

Re: The DROWN Attack

#87

Post by colmmacc »

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…

Another valuable takeaway is that forward secrecy is well worth having. In this case, any previously collected trove of sessions that used DHE/ECDHE is not de-cryptable by using DROWN.

Re: The DROWN Attack

#88

Post by draw_down »

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.

I dunno, bencollier49. Seems like a strange hill to die upon.

Re: The DROWN Attack

#89

Post by cperciva »

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…

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

Re: The DROWN Attack

#90

Post by lawnchair_larry »

tptacek wrote: post #69
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.

I know you didn't mean to do it, but because it's easier for people to snark about attack names, or react to snark, than it is to discuss a complicated crypto attack, this tangent about attack names takes up a pretty big chunk of the thread and really cruds the discussion up. Whatever you might think of the name, this is bona fide important crypto work; it's one of the more interesting TLS attacks ever discovered. Pl…

Then maybe next time they won't distract people with silly marketing, forcing the conversation to be about substance.
Post reply on HN