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?

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:

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.

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.

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.

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.

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