# DROWN Attack - Which is the SSLv2 vulnerability exploited?

In order to get the session key used in TLS communication, an attacker must capture X TLS handshakes based on RSA key encryption, and switch to a server supporting SSLv2 protocol, and sharing the same private key.

The same RSA key lenght is used for encryption between SSLv2 server / TLS 1.2 server in order to use the attack right ?

So why it is mandatory to switch to a server supporting SSLv2? Can you explain me the SSLv2 vulnerability exploited in the case of a DROWN attack?

Thanks.

• Have a look at the bear's canonical answer on this question on secse- – SEJPM May 8 '16 at 19:36
• bear's canonical answer is pretty good, but that does not answer to my problem. If I'm right, both SSLv2 and TLS can use RSA-based key exchange with PKCS#1 v1.5 padding. So both are vulnerable to Bleichenbacher's attack right? So what's the purpose of using SSLv2? – Duke Nukem May 8 '16 at 20:55

SSLv2 has the property that after it receives an encryption of the pre-master secret, the server sends a message that uses the derived key. (This is unlike SSLv3 where the server first checks the MAC from the client.) Now, when using a ciphersuite with 40-bit keys, it is possible to brute force and find the derived key. Importantly, in SSLv2, the derived key is just 40 bits of the pre-master secret (no hashing or anything). So, this gives an oracle for finding 40 bits of the pre-master secret. It is possible to use this to quickly find all of the bits of the pre-master secret, 40 bits at a time.

Some more details. In SSLv2 the RSA encryption uses PKCS#1 v1.5 padding. In order to prevent Bleichenbacher's attack, if the padding is incorrect the server just chooses a random secret and uses that instead (this fix was used throughout SSL versions). Thus, an attacker modifying the ciphertext cannot know if the padding was incorrect and this is a random value or if the padding was correct and this is the real value. The DROWN attack works by sending the SSLv2 server the same modified ciphertext twice. If the same key is used to compute the server reply both times, then the attacker knows that the padding was correct. (It also gets more information since as I wrote it gets 40 bits of the plaintext.) If the same result is not received both times, then the attacker knows that the padding was incorrect. The attacker knows if the same key was used since it just needs to brute force one of the messages in $2^{40}$ time to get the key. It can then try and see if that key matches the other ciphertext. All of this works since the server replies immediately and the attacker does not need to send a message with a correct MAC in order to get the server reply.

Note that this isn't the exact Bleichenbacher oracle, but it's a "Bleichenbacher-type" oracle.

• I understand your answer. However, I need more information please : why is it considered as Bleichenbacher’s attack oracle so? More specificly, as "oracle"? Is it the fact that the server send the ServerVerify containing the derived session key instead of checking the MAC in SSLv2? – Duke Nukem May 10 '16 at 8:50
• I have added more details. – Yehuda Lindell May 10 '16 at 10:03