RFC Errata
RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008
Note: This RFC has been obsoleted by RFC 8446
Source of RFC: tls (sec)See Also: RFC 5246 w/ inline errata
Errata ID: 2643
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Matt McCutchen
Date Reported: 2010-11-22
Verifier Name: Sean Turner
Date Verified: 2011-03-09
Section E.3 says:
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match).
It should say:
When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these 8 padding bytes are not all 0x03. If they are, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match).
Notes:
The condition is the wrong way around. When the bytes *are* all 0x03, that means the client supports TLS, so there must have been a version rollback attack in order for SSL 2.0 to be negotiated. For example, see the NSS implementation (line number may rot):
https://mxr.mozilla.org/mozilla/source/security/nss/lib/ssl/sslcon.c#1695