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

191–200 of 206 posts

Re: The DROWN Attack

#191

Post by Nimi »

Gibbon1 wrote: post #190
Natanael_L wrote: post #188

Earlier quoted context omitted.

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.

Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?

Re: The DROWN Attack

#192

Post by yeukhon »

dadrian wrote: post #45
jvehent wrote: post #17

From a pool of 11 million scans of HTTPS sites, I could only find ~265k targets with SSLv2 enabled [1]. That's 2.4%, not 25%. A breakdown of the type of target that have SSLv2 enabled would be useful to understand how they reached that number. It's possible that they scanned much much more than HTTPS on port 443, and found a lot of embedded devices with poor SSL configurations. At any rate, you should verify the conf…

Due to CVE-2015-3197, many servers using OpenSSL reported they supported no SSLv2 ciphers, which causes OpenSSL-based SSLv2 clients to hang up. However, if you aggressively choose a cipher and continue the handshake, the server will still negotiate the connection. As a result, most existing scanning tools vastly underestimate SSLv2 support.

Wait, what? Is there a PoC script?

Re: The DROWN Attack

#193

Post by developer2 »

For those using nginx:

All nginx versions >= 0.8.19 (Oct 2009), and backported to >= 0.7.65 (Feb 2010), have SSLv2 disabled in default configuration[1][2]. Versions >= 1.9.1 (May 2015) also disable SSLv3 by default, which is not affected by this particular attack but suffers from the POODLE attack.

If you are on a version of nginx covered above, just ensure your nginx configuration does not have an "ssl_protocols" directive explicitly enabling SSLv2 (and SSLv3 for POODLE).

If you are on an older affected version of nginx, check your configuration to make sure you exclude SSLv2 (and typically SSLv3) with something like:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;

It is not necessary to worry whether your nginx is built against openssl 1.0.2g, as this release simply disables SSLv2 support by default. If you've covered your bases with your nginx configuration, the openssl update is not strictly required.

[1] http://nginx.org/en/docs/http/configuring_https_servers.html (versions listed at very bottom of page)

[2] https://drownattack.com/nginx

Re: The DROWN Attack

#195

Post by caf »

tptacek wrote: post #186
skybrian wrote: post #184

Earlier quoted context omitted.

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

Well, at a high enough level there is some connection there.

I think everyone can understand why "Error: The fourth character of your password is wrong" is both more "usable" and insecure.

Re: The DROWN Attack

#196

Post by digi_owl »

tptacek wrote: post #186
skybrian wrote: post #184

Earlier quoted context omitted.

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

A tradition i would love to see go byebye.

Had to deal with a program recently that gave "corrupted MAC" error on the server. All searching etc hinted at it being a network issue. Only after having fiddled with the network for ages and getting nowhere did i set up a loopback test and found the same error.

Turns out the program i was dealing with was using an old lib.

Re: The DROWN Attack

#197

Post by mkj »

Dylan16807 wrote: post #115
CiPHPerCoder wrote: post #94

Earlier quoted context omitted.

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 cryptographer…

Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia? My threat model includes NSA dragnets but not being specifically targeted by the NSA.

NSA dragnets won't decrypt things using dodgy curves for signatures (ECDSA), only things using dodgy curves for key exchange (ECDH).

Re: The DROWN Attack

#198

Post by Natanael_L »

Nimi wrote: post #191
Gibbon1 wrote: post #190

Earlier quoted context omitted.

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.

Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?

Then a bunch of big companies announce they'll use another browser to be able to keep using it

Re: The DROWN Attack

#199

Post by Nimi »

Natanael_L wrote: post #198
Nimi wrote: post #191

Earlier quoted context omitted.

Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?

Then a bunch of big companies announce they'll use another browser to be able to keep using it

Another browser beside Chrome, Firefox and IE? OK, so Symantec announces that they will only use Opera. Even then, they have to deal with their customers, website operators who need a certificate trusted by the big 3 browsers, leaving. In fact, now that Let's Encrypt certificates are free, it seems like this is the Symantec CA's worst nightmare.

Re: The DROWN Attack

#200

Post by nl »

Nimi wrote: post #191
Gibbon1 wrote: post #190

Earlier quoted context omitted.

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.

Fascinating. I still feel I'm missing something basic here: If Microsoft, Google and Mozilla announce they're not going to accept any particular crypto primitive two years from now, and this time there won't be any exceptions, CAs and websites just have to abide, don't they?

The browsers say what they accept, the server says what it provides and something in the intersecting set will be used.

If (as a random example that didn't annoy me at all for 2 years) a website also needs to support SmartTV devices which only accept obsolete certificates then your server has to either break them or not.

Post reply on HN