# Why is this a fix to Bleichenbacher's attack?

Looking at this excellent explaination of the attack, I have one additional question:

It says that: ""To prevent this attack, SSL servers do not inform the client about padding woes. If decryption fails because of a bad padding, then the server continues with a random pre-master secret (the true failure will then occur when processing the Finished message).""

Why does this prevent the attack? Why doesn't the attacker just infer that the connection failed because of the bad padding? Why else could the connection fail?

• In short: The entire attack is based on being able to distinguish whether the padding is correct or not, and that can be derived if the server immediately sends an error message on detecting a wrong padding. – tylo Mar 13 '15 at 13:25
• But my question is: Why can't that still be derived with the fix? – Mark Mar 13 '15 at 13:32
• Basically, if the computation time/length/effort/energy consumption/other_sidechannel is independent of whether the PKCS format has been fulfilled or not, then there is no information to do the attack. – tylo Mar 13 '15 at 14:09

Why does this prevent the attack? Why doesn't the attacker just infer that the connection failed because of the bad padding? Why else could the connection fail?

Well, the connection may fail because the host decrypted a valid pre-master secret, and it wasn't the pre-master secret that we expect.

That is, when the attacker injects his encrypted message, one of two things can happen:

1. The server attempts to decrypt the message, and finds that the padding is invalid

2. The server decrypts the message, and finds a value there.

The information that the attacker needs to know is whether (1) or (2) happened; if he can determine that, then he knows whether the padding looked correct or not.

Now, with the attack, if (2) happens, then the attacker has no idea what the value would be. Hence, if we react to (1) in a way that mimics the behavior in (2), we prevent the attacker from learning that.

• Oh, of course! The attacker doesn't know what pms he actually chose, because he doesn't have a clue what ms is, so the connection failure at the end of the handshake could either mean (i) Attacker used bad padding or (ii) Attacker screwed up the encrypted Finished messages because he didn't know what the pms was. Right? – Mark Mar 13 '15 at 14:14
• That is correct – poncho Mar 13 '15 at 14:16
• As an additional note, in the fix, the server isn't even acting as a decryption oracle right? – Mark Mar 13 '15 at 14:32
• ...and before the fix the server is just acting as a padding verification oracle, right? – Mark Mar 13 '15 at 14:33
• @Mark: correct; the attacker was using the server as such an Oracle; this change in behavior prevents that. – poncho Mar 13 '15 at 14:51

Bleichenbacher's attack relies on being able to determine whether the padding was correct or not. The patch tries to ensure that the following two (previously distinguishable) cases look identical to an attacker:

• the padding was correct, but the attacker has no knowledge of the transmitted pre-master secret — hence he can't use the resulting symmetric keys to generate a correctly encrypted and authenticated record, resulting in a connection failure.
• the padding was incorrect, so the server creates a pseudorandom pre-master secret — thus the resulting symmetric keys are pseudorandom and, just like in the other case, the attacker is unable to generate a valid record, so the connection fails.

Assuming the patch is properly implemented, this makes plausible that the previously exploitable padding oracle no longer exists, rendering the attack unapplicable.

• Oh, of course! The attacker doesn't know what pms he actually chose, because he doesn't have a clue what $ms$ is, so the connection failure at the end of the handshake could either mean (i) Attacker used bad padding or (ii) Attacker screwed up the encrypted Finished messages because he didn't know what the pms was. Right? – Mark Mar 13 '15 at 14:11