Live data from Hacker News

The DROWN Attack

drownattack.com

71–80 of 206 posts

Re: The DROWN Attack

#71

If you want to check your servers for various other attacks with a shell script: https://testssl.sh/ Also, I'm not seeing any guides on fixes for Dovecot yet. If you built from source or the defaults aren't working, you can use the following: ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL Something more secure (blocks other vulnerabilities): ssl_cipher_list = ALL:!ADH:!LOW:!SSLv2:!SSLv3:!EXP:!aNULL:!RC4:+HIGH:+MEDIUM…

  ssl_cipher_list = ALL:!LOW:!SSLv2:!EXP:!aNULL
Does this just disable all SSLv2 ciphers, or disable SSLv2 via SSL_OP_NO_SSLv2? The former might not be enough, unless your OpenSSL version includes fixes from 1.0.2f and g.

Re: The DROWN Attack

#72
> Disabling SSLv2 can be complicated [...]

If users are accidentally enabling a feature that's been insecure for 20 years, the vulnerability is that your configuration mechanism is too complicated to understand.

Re: The DROWN Attack

#73

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.

Well how long before the novelty names run out of meaning ? For starters there are probably more issues out there then there are catchy American English anachronisms. I vote for using the names of Mezzo-American gods . Like Hachäk'yum or Xbalanque!

I think GitHub should starting doing something this for issues and pull requests.

Instead of the nondescript

- Issue #2654: misplaced comma on page 3 of documentation

- Issue #2653: open() should accept relative file path

it should be

- Quetzalcoatl's Rage: misplaced comma on page 3 of documentation

- The Dying Curse of Buluc Chabtan: open() should accept relative file path

Re: The DROWN Attack

#74

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'm on the fence over the "marketing". On one hand it is easier to communicate terms like DROWN, GHOST and Heartbleed than say CVE-2016-0800; meaning knowledge of the vulnerability gets spreads quicker and sites are patched more readily. Alternatively it could be a distraction from good security management practices, where only the "marketed" vulnerabilities get patched instead of general tracking the security of cri…

Yep; at this point, non-technical management is trained that "it's serious if it's got a cool name."

Re: The DROWN Attack

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

As JP Aumasson said https://twitter.com/veorq/status/683360050199552001

    1998: Bleichenbacher's padding oracle attack on RSA
    2016: still vulnerable systems
    http://framework.zend.com/security/advisory/ZF2015-10
I second "stop using RSA".

Re: The DROWN Attack

#76
post #44

Earlier quoted context omitted.

Ok, is there any CVE that covers this attack / disables SSLv2? This is rather in-transparent to me. Would be nice, if somebody could give better advice on this soon.

DROWN is CVE-2016-0800. There are a lot of CVE's in openssl's advisory released 10 minutes ago: https://www.openssl.org/news/secadv/20160301.txt None are fixed yet of course in debian. And not in ubuntu either: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssl/...

Actually Ubuntu is not affected because it already has SSLv2 disabled: http://people.canonical.com/~ubuntu-security/cve/2016/CVE-20...

You won't see a fix appear in the changelog because there is nothing to fix in the Ubuntu packages.

Re: The DROWN Attack

#78
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 safe - are usable with X.509 and TLS, yet. Still waiting for that RFC to get past the draft status.

So, what should we do?

Re: The DROWN Attack

#80
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.
Post reply on HN