Dear all,

RFC 7457 states:
"While the Bleichenbacher attack has been mitigated in TLS 1.0, the
Klima attack, which relies on a version-check oracle, is only mitigated
by TLS 1.1."

RFC 2246 (TLS 1.0) states:
"The best way to avoid vulnerability to this attack is to treat
incorrectly formatted messages in a manner indistinguishable from
correctly formatted RSA blocks. Thus, when it receives an
incorrectly formatted RSA block, a server should generate a
random 48-byte value and proceed using it as the premaster
secret. Thus, the server will act identically whether the
received RSA block is correctly encoded or not."

This does not safely prevent Bleichenbacher style attacks. To rephrase
it: implementations should generate and proceed with a random PMS if
(implied "*and only if*") an incorrectly formatted message was received.
This opens a timing side channel that we successfully exploited in
several TLS implementations that comply with RFC 2246 (see [1], [2]).

This timing side channel was first addressed in TLS 1.2 (RFC 5246),
which gives the following timing-constant algorithm to prevent
Bleichenbacher's attack:
"1. Generate a string R of 46 random bytes
2. Decrypt the message to recover the plaintext M
3. If the PKCS#1 padding is not correct, or the length of message
     M is not exactly 48 bytes:
        pre_master_secret = ClientHello.client_version || R
     else If ClientHello.client_version <= TLS 1.0, and version
     number check is explicitly disabled:
        pre_master_secret = M
     else:
        pre_master_secret = ClientHello.client_version || M[2..47]"


Thus, it is not TLS 1.0 which safely prevents Bleichenbacher attacks,
but TLS 1.2.

Best regards,
Sebastian


[1]: Revisiting SSL/TLS Implementations: New Bleichenbacher Side
Channels and Attacks. Meyer, Somorovsky, Weiss, Schwenk, Schinzel, Tews.
23rd Usenix Security Symposium 2014.
[2]: Revisiting SSL/TLS Implementations. 31. Chaos Communication
Congress. http://events.ccc.de/congress/2014/Fahrplan/events/5960.html

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta

Reply via email to