The DROWN Attack • Hacker News Board

Re: The DROWN Attack

#161

Post by DanielDent » Tue, Mar 01, 2016, 9:28 PM UTC

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…

> To me, the real takeaway: RSA is obsolete. Stop using it.

RSA also has the nice property of being deterministic.

ECDSA may not be, depending on how you implement it. EDDSA is.

This matters a great deal in a world where it's important to assume your hardware may have some adversarial properties. It's much easier for your ECDSA device to purposefully leak your private key than it is for RSA (both because there's an explicit covert channel available, and also because of how much smaller elliptic key-pairs are in practice).

Also, as we prepare for a post-quantum crypto world, this might be a bad time for shorter keylengths.

There are lots of great reasons to use curves, but I think describing RSA as obsolete is a little premature.

Re: The DROWN Attack

#162

Post by pfg » Tue, Mar 01, 2016, 9:28 PM UTC

DenisM wrote: post #151

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…

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

> Everyone who had sslv2 enabled at any point in the past must get a new SSL certificate right away. Right?

No, unlike Heartbleed, the key isn't leaked directly. Revocation and generating a new key isn't necessary - just patch your stuff and disable SSLv2.

> Windows XP has TLS disabled by default, which in practice means unavailable. So we must cut them off. Therefore Windows XP is dead-dead, starting today. Right?

IIRC XP supports TLS 1.0.

Re: The DROWN Attack

#163

Post by syncsynchalt » Tue, Mar 01, 2016, 9:31 PM UTC

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.

Also, disabling SSLv2 in versions of openssl up til January did not actually disable SSLv2.

Re: The DROWN Attack

#164

Post by tptacek » Tue, Mar 01, 2016, 9:37 PM UTC

DanielDent wrote: post #161

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…

> To me, the real takeaway: RSA is obsolete. Stop using it. RSA also has the nice property of being deterministic. ECDSA may not be, depending on how you implement it. EDDSA is. This matters a great deal in a world where it's important to assume your hardware may have some adversarial properties. It's much easier for your ECDSA device to purposefully leak your private key than it is for RSA (both because there's an e…

Don't use ECDSA, and don't use RSA.

I don't think reasonable key lengths are going to make much of a difference if quantum computing becomes a practical threat. All the RSA cryptosystems and all the ECC cryptosystems will fall.

Meanwhile: the literature suggests that RSA and classical DH keys are threatened much more by conventional computing advances than curve keys; curve keys resist index calculus attacks.

Re: The DROWN Attack

#165

Post by yuhong » Tue, Mar 01, 2016, 9:39 PM UTC

DenisM wrote: post #151

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…

This sounds really bad. Is it? So, if a server is accepting sslv2 at all, then all connection (including TLS connections) to the same server are practically compromised. That is, assuming both sslv2 and TLS use the same key. Therefore, having allowed sslv2 in the past would only jeopardize clients foolish enough to use it, but now it endangers every single client. Is that right? Two very important things come form th…

Only if they are using IE6 I think. That being said, I think there are some IE7 and IE8 upgrades that inherits the old default from IE6.

Re: The DROWN Attack

#166

Post by cantrevealname » Tue, Mar 01, 2016, 9:41 PM UTC

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 top line takeaway on DROWN for most people seems to be "export ciphers are evil". I think: (a) boring! (b) misses the more important point.

The US government never misses a propaganda opportunity: "uncrackable crypto and impenetrable devices are evil". But technical people so easily miss the marketing value of sound bites.

This is a clear-cut case in which yet another major Internet security vulnerability is significantly caused by US government policy. Why shouldn't we run with this as a way to explain to the public why regulation of crypto is bad?

Re: The DROWN Attack

#167

Post by yuhong » Tue, Mar 01, 2016, 9:41 PM UTC

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…

Please don't put !SSLv3 in the cipher list. I had to help out Pinboard who did this: https://twitter.com/yuhong2/status/602545883775836161

Re: The DROWN Attack

#168

Post by IgorPartola » Tue, Mar 01, 2016, 9:43 PM UTC

sandworm101 wrote: post #108

Someone1234 wrote: post #105

Earlier quoted context omitted.

Are you shielding the keyboard from EM leakage? I don't open a cage, I get in one and do my work in there... No more EM eavesdropping.

Unless there is an enemy antenna with you inside the cage. A real security pro uses a pneumatic keyboard.

No magnetized needle and a steady hand?

Re: The DROWN Attack

#169

Post by stock_toaster » Tue, Mar 01, 2016, 9:49 PM UTC

tptacek wrote: post #154

stock_toaster wrote: post #152

Earlier quoted context omitted.

What about the NSA "freaking out"[1] about ECC in general? [1]: http://blog.cryptographyengineering.com/2015/10/a-riddle-wra...

Rodents of unusual size? I don't think they exist.

Your vote of confidence is overwhelming. ;)

Re: The DROWN Attack

#170

Post by cantrevealname » Tue, Mar 01, 2016, 9:56 PM UTC

pekk wrote: post #159

tamana wrote: post #97

Why does everyone bug need its own domain name?

If you look at the bottom of the page, you will see that some of the underlying motivation for the site is to shill for a particular political stance.

> shill for a particular political stance

Government agencies lobby for what they want (restrictions on speech, limits on privacy, back doors into crypto), but we technical people should stick to technical discussion only?

A technical report should never discuss what government policy caused the bug, political decisions that could have avoided it, and their effect on society?

By the way (to save a click), the political stance is this (quoted from the article):

"Today, some policy makers are calling for new restrictions on the design of cryptography in order to prevent law enforcement from “going dark.” While we believe that advocates of such backdoors are acting out of a good faith desire to protect their countries, history’s technical lesson is clear: weakening cryptography carries enormous risk to all of our security."