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

121–130 of 206 posts

Re: The DROWN Attack

#121

Post by api »

This is why complexity is so terribly evil in secure protocols. All these features, feature flags, upgrades, downgrades, state transitions... it's all surface area for bugs. A complete state diagram for a modern SSL/TLS stack would be huge and contains edge cases that are probably undocumented and poorly understood.

Do boring crypto: https://cr.yp.to/talks/2015.10.05/slides-djb-20151005-a4.pdf

Boring crypto means minimal state, minimal code (and therefore easy to audit), a minimal set of algorithms with new algorithms and encodings and such being added only when absolutely necessary, etc. Crypto "flexibility" means edge case bugs and lots of code where bugs can hide.

There is in general an exponential relationship between LOC and complexity and bugs. In crypto and security code this is really bad.

Re: The DROWN Attack

#122

Post by Dylan16807 »

CiPHPerCoder wrote: post #120
Dylan16807 wrote: post #115

Earlier quoted context omitted.

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.

So this is something that can't be done en masse? Okay, thanks.

Re: The DROWN Attack

#123

Post by davidamarquis »

tptacek wrote: post #104
matthewdgreen wrote: post #95

Earlier quoted context omitted.

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

RSA OAEP and PSS is just as unlikely to win the Internet as ECDH and curve signatures. But if you had to pick one to win, you'd pick curves.

What are the arguments against RSA OAEP?

Re: The DROWN Attack

#124

Post by PythonicAlpha »

drewcrawford wrote: post #51
PythonicAlpha wrote: post #34

Earlier quoted context omitted.

To make it more clear: According to the info page, I can disable SSLv2 on OpenSSL only by installing a newer version of OpenSSL, that is not available on Debian (as I found). (I also updated my original post)

You misunderstand how Debian works. Debian practically never updates to new versions of software (until you upgrade Debian). Instead they "backport" security fixes into the older software versions, preserving the old version numbers but adding some stuff on the end to reflect Debian's changes. The intent is that you get "only" security fixes, never features or improvements. So when you see "OpenSSL-1.0.c-stuffgoesher…

> you might be happier with a commercial vendor

Might be a viable option.

I just don't know a commercial vendor, that also gives more transparency.

I knew, that there are also fixes from the Debian team, that add to the core functionality. But still my problem is the transparency. It is just very difficult in such a case, to find out the relevant changes, if you lack the time to observe all security changes in the distribution.

When such a thing pops up, like today, it is very tedious work for people like me, to find all the strings involved. So many packages, that can potentially involved, so many applications (eg. WebServer, SSH-Server, ...) and everywhere could be a hole. Here, I would appreciate, some more focused information, about the particular distribution.

I am using Debian because of its good reputation -- but of course if you could point out a commercial distribution with more transparency, it would be worthwhile!

Re: The DROWN Attack

#125

Post by michaelbuckbee »

themodelplumber wrote: post #116
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

Imagine it like you're looking through a keyhole at a computer monitor.

It's setup so that you can only see the very last letter in what you think is a really long sentence someone has typed into a text editor.

With your bluetooth keyboard you move to the beginning of the line and repeatedly hit the spacebar, taking note each time what the new letter is that you can see through the keyhole.

Re: The DROWN Attack

#126

Post by tptacek »

davidamarquis wrote: post #123
tptacek wrote: post #104

Earlier quoted context omitted.

RSA OAEP and PSS is just as unlikely to win the Internet as ECDH and curve signatures. But if you had to pick one to win, you'd pick curves.

What are the arguments against RSA OAEP?

Public key encryption transforms are one of the biggest foot-guns in cryptography. OAEP is at least not prima facie broken, but using it still exposes you to the the design risks of building with public key encryption.

(There are attacks against OAEP, but they're less common and not intrinsic to the design the way PKCS1v15's are).

Re: The DROWN Attack

#127

Post by IncRnd »

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.

>> Threat model wrapped in tin foil? I don't understand what you mean, are you suggesting paranoia?

That term likely means one of two things: guarding against a particularly capable attacker or paranoia for others

Re: The DROWN Attack

#128

Post by PythonicAlpha »

pferde wrote: post #65
PythonicAlpha wrote: post #25

According to the info page, SSLv2 can only be disabled on OpenSSL by having the right (newer) version of OpenSSL installed. I just checked Debian versions. Wheezy (oldstable): Much to old OpenSSL versions, according to the info site Jessy (stable): Still to old OpenSSL version. Stretch (testing): Still to old OpenSSL version. Sid (unstable): The same version of OpenSSL as Stretch -- Still to old. What to do?

From the recent Debian security advisory (DSA-3500-1) about this: "Additionally the EXPORT and LOW ciphers were disabled since thay could be used as part of the DROWN (CVE-2016-0800) and SLOTH (CVE-2015-7575) attacks, but note that the oldstable (wheezye)[sic!] and stable (jessie) distributions are not affected by those attacks since the SSLv2 protocol has already been dropped in the openssl package version 1.0.0c-2.…

Thank you very much!

Re: The DROWN Attack

#129

Post by tptacek »

themodelplumber wrote: post #116
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

An "oracle" is simply an circumstance in which an adversary can coerce you to use your secret key to do a useful computation, some result of which is revealed.

Padding oracles are a subset of "error oracles", which are oracles that come from exception processing. The "useful computation" you're being forced into doing is "decrypting, checking for errors, and then somehow signaling the error."

Think of error oracles this way: imagine a situation in which an adversary can hand you a ciphertext which, when decrypted, will trigger an error (in a padding oracle, that error is "the padding is wrong"). Now imagine that the error, revealed to the adversary, allows them to infer one bit of the plaintext. Not very useful by itself, but, as a final step, imagine that the attacker can permute the same ciphertext, generating (or not generating) an error and allowing them to reveal a different bit of the plaintext.

As long as they can keep doing that, they'll eventually recover the whole plaintext.

Here's a good starting point:

http://cryptopals.com/sets/6/challenges/46/

Post reply on HN