Return to Answer

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.

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

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.

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

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.

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.

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

• 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 2⁵⁰ operations.

• 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 2⁵⁰ operations.