Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

There is a new recent attack "on TLS" named "DROWN". I understand that it appears to use bad SSLv2 requests to recover static (certificate) keys.

My question is: How?

How can you recover static encryption or signature keys using SSLv2?

Bonus questions: How can I prevent the attack from applying to me as a server admin? How could the attack spawn in the first place?

share|improve this question
23  
Official link from the discovers: drownattack.com includes full paper on this issue, including details of the variants, and the numbers of machines likely to be affected. – Matthew Mar 1 at 13:38
36  
The obsession with five-letter acronyms baffles me. – Deer Hunter Mar 1 at 14:15
9  
@DeerHunter TLAs are so last decade... – Mason Wheeler Mar 1 at 15:46
7  
@DeerHunter To be fair, another attack against SSL, POODLE, is 6 letters :) – iismathwizard Mar 1 at 16:13
18  
@MasonWheeler DETLA - Double Extended Three Letter Acronym (link) – TripeHound Mar 1 at 16:33
up vote 236 down vote accepted

To understand the attack, one must recall Bleichenbacher's attack from the late 20th century. In that attack, the attacker uses the target server as an oracle. When using RSA-based key exchange, the client is supposed to send a secret value (the "pre-master secret") encrypted with the server's public key, using PKCS#1 v1.5 padding (called "type 2"). Bleichenbacher's attack relied on sending carefully crafted values in lieu of a properly encrypted message, and observe the server's reaction. The server might respond (most of the time) with an error saying "I processed that but it did not yield a proper PKCS#1 v1.5 type 2 padding"; but sometimes, the decryption seems to work and the server proceeds with whatever it obtained. The attacker sees that difference in behaviour, and thus gains a tiny bit on information on the private key. After a million connections or so, the attacker knows enough to perform an arbitrary decryption and thus break a previously recorded session.

This attack is of the same kind, but with a new technique that relies on the specificities of SSL 2.0. SSL 2.0 is an old protocol version that has several serious flaws and should not be used. It has been deprecated for more than 15 years. It has been even formally prohibited in 2011. Nevertheless, some people still support SSL 2.0. Even worse, they support it with so-called "export" cipher suites where encryption strength is down to about 40 bits.

So the attack works a bit like this:

  1. The attacker observes an encrypted SSL/TLS session (a modern, robust one, say TLS 1.2) that uses RSA key exchange, and he would like to decrypt it. Not all SSL/TLS sessions are amenable to the attack as described; there is a probability of about 1/1000 that the attack works. So the attacker will need to gather about a thousand encrypted sessions, and will ultimately break through one of them. The authors argue that in a setup which looks like the ones for CRIME and BEAST (hostile Javascript that triggers invisible connections in the background), this collection can be automated.

  2. The server carelessly uses the same RSA private key for a SSL 2.0 system (maybe the same server, maybe another software system that may implement another protocol, e.g. a mail server). The attacker has the possibility to try to talk to that other system.

  3. The attacker begins a SSL 2.0 handshake with that system, using as ClientMasterKey message a value derived from the one that the attacker wants to decrypt. He also asks for using a 40-bit export cipher suite.

  4. The attacker observes the server's response, and brute-forces the 40-bit value that the server came up with when it decrypted the value sent by the attacker. At that point, the attacker knows part of the result of the processing of his crafted value by the server with its private key. This indirectly yields a bit of information on the encrypted message that the attacker is really interested in.

  5. The attacker needs to do steps 3 and 4 about a few thousand times, in order to recover the encrypted pre-master secret from the target session.

For the mathematical details, read the article.

Conditions for application:

  • The connection must use RSA key exchange. The attack, as described, cannot do much against a connection that uses DHE or ECDHE key exchange (which are recommended anyway for forward secrecy).

  • The same private key must be used in a system that implements SSL 2.0, accessible to the attacker, and that furthermore accepts to negotiate an "export" cipher suite.
    Note: If OpenSSL is used and not patched for CVE-2015-3197, even if "export" cipher suites are disabled, a malicious client can still negotiate and complete a handshake with those disabled cipher suites.

  • The attacker must be able to make a few thousands or so connections to that SSL 2.0 system, and then run a 40-bit brute force for each; the total computing cost is about 250 operations.

It must be well understood that the 250 effort is for each connection that the attacker tries to decrypt. If he wants to, say, read credit card numbers from connections he observes, he will need to make a non-negligible amount of work for each credit card number. While the attack is very serious, it is not really practical in that CCN-grabbing setup.


The solution: don't use SSL 2.0. Dammit. You should have stopped using SSL 2.0 in the previous millenium. When we said "don't use it, it is weak", we really meant it. It is high time to wake up and do your job.

Supporting weak ("export") cipher suites was not a smart move either. Guess what ? Weak crypto is weak.

Deactivating SSL 2.0 is the only right way to fix the issue. While you are at it, deactivate SSL 3.0 as well.

(And that fashion of using all-uppercase acronyms for attacks is really ridiculous.)

share|improve this answer
48  
I didn't ever bother reading anything but the title of the question to know that I'll find you answering the question, the community and I can't thank you enough, you are a diamond. – Ulkoma Mar 1 at 15:19
18  
Yeah. And when I see the bear answer, I upvote it, then start reading. Thanks for everything you do. The moderators here don't like thank you comments but in this case they should get an exception. – void_in Mar 1 at 16:34
2  
Also note that there are circumstances in the paper under which you can do a "Special DROWN" attack that takes ~1 minute on a single CPU core. – Riking Mar 1 at 18:12
2  
Do I understand correctly that this requires a double flaw: not just offering SSL 2.0, but additionally reusing the same private key between SSL 2.0 and TLS 1.2 connections? – MSalters Mar 1 at 20:09
6  
Not sure I'm quite ready to talk about network protocol attacks in terms of "late Nth century" yet. ;-) – loneboat Mar 2 at 22:15

The answer by Thomas is wonderful. There is just one thing that seems understated: e-mail servers are broken security-wise... by default and by design.

  • default: just look at the default postfix configuration for instance (hint: SSLv2 and 40-56bit ciphers are still a thing, and "no encryption" too).
  • by design: have you ever heard of the StartSSL wonder? Well, it is the only non-deprecated way to achieve encryption with SMTP (the "e-mail" protocol). What's wonderful with StartSSL is that it is usually strong when nobody is listening, but can be easily made to default to clear text if someone wants to read... or SSLv2 if someone wants to read HTTPS instead...

    ¯\_(ツ)_/¯

See there for an example of both the state of mind of people in the SMTP realm and a few glimpses of configuration. Please note that there is no such thing as a single flag to disable SSLv2 in postfix (well, there is one, but don't be surprised if the server still accepts and responds to SSLv2 afterwards).

How is that even related to the question?

You can harden your web server as much as you want, if you have a SMTP server running on a valid certificate, chances are high that you are vulnerable to that same "DROWN" attack. Even worse, your web server will be too... well usually: you'd be surprised by how many SMTP servers share their certificates with the HTTP server. You'd also be surprise by the validity domain of some "stand-alone" SMTP certificates.

Solutions?

  1. Configure your SMTP server properly (and check the configuration with external tools such as sslyze)
  2. Or disable SMTP altogether.
  3. Or use a self-signed/subdomain-specific certificate with SMTP.
share|improve this answer
2  
1. is not a solution I'm afraid. What is the point of disabling weak crypto when it results in connections falling back to plain text? 2. is a solution, assuming you can do without email. 3. is probably the realistic solution and in practice, many MX servers use self-signed certificates. What value do CA bring to SMTP anyway? RFC 7672 provides both a good discussion of the subject and a long term solution: tools.ietf.org/html/rfc7672 Note that the problem is with MTA to MTA connections, not with MUA to MTA submission. (assuming proper configuration) – Erwan Legrand Mar 2 at 10:04
    
By "1." I meant "use the 'deprecated' plain-TLS scheme with only strong ciphers". If the connection fails because the remote end can't talk to your server, well that's a shame but this is the price for security (at least on your end as there is no such thing as end-to-end encryption in SMTP). 3. I agree, but it's not there yet and "opportunistic" usually equals "susceptible to downgrade attacks". :) – JPatta Mar 2 at 11:26
    
Also, with regards to "1." what is the point of enabling weak crypto if it results in connections susceptible to this kind of attacks? These are arguably worse than plain text given that StartSSL can already, with virtually no effort, provide plain text to any active attacker and that, as you rightfully said yourself, having strong crypto between your MTA and the distant MTA does not guaranty that all the remaining MTA to MTA connections were encrypted. – JPatta Mar 2 at 11:37
2  
I don't think StartTLS is "broken by design". Yes, you can circumvent it via a MITM, but that is detectable by the client. The problem is not StartTLS, but that most SMTP clients will accept a connection without TLS - and that is for backwards compatibiliy. If anything, blame SMTP itself. And SSMTP on its own port has the same problem - you can block the port, and clients will re-try on port 25 w/o TLS. – sleske Mar 2 at 16:58
    
At any rate, if you disable SSLv2/3 on your mail server, you are safe from DROWN. No need for a self-signed cert (which would cause other problems). – sleske Mar 2 at 16:59

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.