162

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?

Anko
  • 189
  • 10
SEJPM
  • 9,500
  • 5
  • 35
  • 66

2 Answers2

239

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.)

Community
  • 1
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 51
    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 01 '16 at 15:19
  • 19
    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 01 '16 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 01 '16 at 18:12
  • @Riking: yes -- as usual, implementation bugs can really help attackers. But that one is easily fixed by applying published security patches, something that all competent sysadmins already do and don't need to be reminded of. – Thomas Pornin Mar 01 '16 at 18:16
  • 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 01 '16 at 20:09
  • 2
    @MSalters: indeed, the specific flaw is about reusing the same private key. It shows that offering SSL 2.0 support is harmful even when normal clients do not use it. – Thomas Pornin Mar 01 '16 at 20:11
  • 1
    @MSalters Reusing the private key for both implementations isn't necessarily a flaw. The only way to avoid it would be to have a completely separate SSL certificate for the SSLv2 system, which would be pretty unusual. –  Mar 02 '16 at 02:27
  • 6
    Not sure I'm quite ready to talk about network protocol attacks in terms of "late Nth century" yet. ;-) – loneboat Mar 02 '16 at 22:15
  • 1
    You deserve a "God-like" badge if there is such a thing. Your answers are phenomenal. – camden_kid Mar 03 '16 at 16:18
  • Does it mean if a TLS ciphersuite contains RSA as key exchange, and you use the same key pair on a SSLv2 server, you are screwed? i.e. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 – CppLearner Mar 03 '16 at 18:47
  • @CppLearner: Yes. No. I mean, the problem indeed arises if the RSA key is used for key exchange _and_ is also used in a SSLv2 server; but in `TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384`, the key exchange is done with elliptic curve DH, not with RSA. In that suite, RSA is used for server authentication, with a signature, not with encryption. – Thomas Pornin Mar 03 '16 at 18:51
  • @ThomasPornin Thanks for correcting. Sometimes it's hard to remember the order. So TLS_RSA_WITH_AES_128_GCM_SHA256 would be a perfect example. I hope I get it right (prefix, key-exchange, authentication, etc) – CppLearner Mar 03 '16 at 18:59
  • "late 20th century" make me feel like the internet is getting old – Ciro Santilli OurBigBook.com Mar 03 '16 at 20:54
  • @Thomas Pornin - since the attacker needs to initiate thousands of SSL connections (presumably within a short time period), would it make sense to rate limit SYN packets with iptables ? – Martin Vegter Mar 04 '16 at 15:02
  • 1
    It makes sense to worry about many connections in a short time, but not for DROWN. For DROWN, connections need not be in a really short time, since it is ultimatey offline decryption. Also, if you fiddle with SYN packets but do not _kill that bloody SSLv2 server and trample its corpse_, then you are doing things wrong. – Thomas Pornin Mar 04 '16 at 15:05
43

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.
Philipp
  • 48,867
  • 8
  • 127
  • 157
JPatta
  • 664
  • 4
  • 5
  • 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: https://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 02 '16 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 02 '16 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 02 '16 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 02 '16 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 02 '16 at 16:59
  • @sleske Sorry, the wording was not good. So, how would *you* call a protocol **designed** to choose the *best* crypto available but do **exactly the opposite** in case of MITM? And trivially with that: no need to forbid SSL/TLS handshakes or stuff like that: just alter the cleartext crypto protocol negotiation. – JPatta Mar 03 '16 at 09:12
  • I think we all agree that the real culprit here is `SMTP`. However, deprecating `TLS` and favoring `StartSSL` was really too much, especially with today's defaults in `SMTP` severs. Just transpose that with `HTTP`: `StartTLS` is like choosing crypto over `HTTP` on a web server with all the available ciphers of the creation enabled ("plain text" included). If you try to disable one or ask for why it was not actually disabled, you are given names by server folks. Come on, they sarcastically called somebody a "genius" because he dared to ask how to disable `SSLv2` arguing he knows shit. – JPatta Mar 03 '16 at 09:31
  • But anyway, the main point of my answer was to emphasize that `SMTP` servers are vulnerable too and that the problem is hairier than with `HTTP` servers (configuration-wise at the very least). – JPatta Mar 03 '16 at 09:37
  • @JPatta The point of opportunistic encryption is to offer protection against passive attacks. Here, weak crypto is better than no crypto. If the goal is to make active attacks/MITM hard or impossible, what is required is something like DNSEC+DANE+STARTTLS. Once you have blocked trivial active attacks which do no require attacking any crypto, then it is time to worry about weak crypto. At his point worrying about weak crypto in the context of connections to MX servers is (unfortunately) futile. – Erwan Legrand Mar 04 '16 at 12:06
  • @ErwanLegrand I understand the point of opportunistic encryption: it *can* be strong as long as nobody is listening when stuff are actually sent. Can we put that topic into rest now? Regarding the rest, this is a specific case where weak crypto is **worse** than no crypto at all. Hence my contribution because people think `HTTPS` here, not `SMTPS` when they try to mitigate stuff like that. And in this specific regard, web people are just used to set a flag and they are done. I just warned them that it was not that simple with `SMTP` servers. – JPatta Mar 04 '16 at 16:27
  • BTW, I am not worried about weak (or no) crypto of MX servers. Actually, I really think that `SMTP` should have stayed just like this (without a S). Because it gives people the wrong impression that they can expect a bare minimum of security with their emails. This is why I find the very existence of `StartSSL` very ironic. But in the meanwhile, the long obsoleted `SSLv2`, proved insecure multiple times, is still there and it currently *jeopardizes* servers even tough it shouldn't in the first place (and you are called "genius" because you tried to disable it). – JPatta Mar 04 '16 at 16:34