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

111–120 of 206 posts

Re: The DROWN Attack

#111

Post by tptacek »

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…

Use Curve25519.

Re: The DROWN Attack

#112

Post by [deleted] »

skywhopper wrote: post #19

So, disable SSLv2. That is not new information. I like how the FAQ insists you are still at risk if you've disabled SSLv2 because you still might be using it somewhere else!!! In other words, if you've not disabled SSLv2 everywhere, then there are still places where SSLv2 is enabled. Thank you.

[deleted]

Re: The DROWN Attack

#113

Post by tptacek »

cperciva wrote: post #106
tptacek wrote: post #103

Earlier quoted context omitted.

I concede that "RSA is obsolete" is somewhat hyperbolic, given OAEP and PSS, but RSA is dangerous, more dangerous than modern curve crypto. Developers overestimate their ability to mitigate dangers.

I think developers of elliptic curve crypto overestimate their ability too. Avoiding side channels in RSA is easier than avoiding them in ECC - fewer moving parts.

Developers that are likely to expose exploitable side channels in curve software are just as likely to expose them in RSA software. But developers that use curve software are going to avoid a bunch of vulnerabilities that are specific to RSA. They should use curves, and avoid RSA.

But I don't know why I'm letting you off the hook on this. Can you be as specific as you can about the additional moving parts you're referring to? Is your comment about the difficulty of getting constant time key agreement or verification specific to legacy Weierstrass curves? And are you concerned about timing leaks in something other than scalar multiplication? If so, what are those other things?

When you say there are "more moving parts", are you referring to the fact that there's both a modular reduction and a scalar multiplication that need to be protected?

Re: The DROWN Attack

#114

Post by chflags »

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.

This seems like what a sensible person would do.

On the other hand, placing evergreen confidence in "TLS", believing that it is "good enough" or concluding "it's all we've got" are lines of thinking that not make sense to me. The vulnerabilities just keep coming, one after another.

High speed crypto not part of TLS that, as another commenter put it, is "considered safe". Does it exist?

Useful software that is written from the start with such care that it does not need to be continously patched ad inifitum. Nonexistant? (No need to answer. I know the truth.)

Getting something added to TLS seems difficult enough, but getting something removed seems impossible. Like all bad software, TLS has numerous "features" I do not need and will never use. OpenSSL is like a museum of cryptography, preserving the obsolete for posterity.

Long live TLS. May it forever waste my time and energy.

Re: The DROWN Attack

#115

Post by Dylan16807 »

CiPHPerCoder wrote: post #94
_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.

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.

Re: The DROWN Attack

#116

Post by themodelplumber »

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…

> The vulnerability here is tricky to exploit but actually simple to describe.

Yessss finally

> There's a padding oracle

hysterical sobbing sounds

Re: The DROWN Attack

#117

Post by [deleted] »

Mojah wrote: post #18

Oh come on, it targets SSLv2. You better have a _damn_ good reason for still having SSLv2 enabled on your systems. If you didn't, you had this one coming.

[deleted]

Re: The DROWN Attack

#119

Post by capnrefsmmat »

pfg wrote: post #71
jqueryin wrote: post #22

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.

Dovecot also supports disabling SSLv2 directly:

    ssl_protocols = !SSLv2 !SSLv3

Re: The DROWN Attack

#120

Post by CiPHPerCoder »

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.

In that case, active attacks against Weierstrass field arithmetic isn't part of your threat model and ECDSA/ECDH over the NIST curves is fine.
Post reply on HN