RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 7457, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", February 2015

Source of RFC: uta (sec)
See Also: RFC 7457 w/ inline errata

Errata ID: 4403
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Sebastian Schinzel
Date Reported: 2015-06-28
Verifier Name: Stephen Farrell
Date Verified: 2015-06-29

Section 2.7 says:

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.

It should say:

The Bleichenbacher attack has been first addressed in TLS 1.0. This
mitigation closed the error message-based attack, but opened a
potentially exploitable timing leak [*] which has been addressed in
TLS 1.2. The Klima attack, which relies on a version-check oracle,
is mitigated by TLS 1.1.

[*]: Revisiting SSL/TLS Implementations: New Bleichenbacher Side
Channels and Attacks. Meyer, Somorovsky, Weiss, Schwenk, Schinzel,
Tews.  23rd Usenix Security Symposium 2014.

Notes:

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.

Report New Errata



Advanced Search