RFC 5246, "The Transport Layer Security (TLS) Protocol Version 1.2", August 2008

Note: This RFC has been obsoleted by RFC 8446

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

Report New Errata