The SSL 2.0 CLIENT-HELLO format precludes the use of TLS extensions, which can only be sent as part of an (Extended) ClientHello handshake message, making SSL 2.0 compatibility increasingly costly to maintain.

tls

The number of servers supporting the 'MAY accept' SSL 2.0 CLIENT-HELLO format is declining; this option does not permit actual negotiation of SSL 2.0, only parsing of its handshake format.

tls

TLS clients MUST NOT send the SSL version 2.0 compatible CLIENT-HELLO message format, and MUST NOT send any ClientHello message that specifies a protocol version less than { 0x03, 0x00 }.

tls, security

TLS clients SHOULD specify the highest protocol version they support in the ClientHello message.

tls

TLS servers MAY continue to accept ClientHello messages in the version 2 CLIENT-HELLO format as specified in RFC 5246 Appendix E.2, provided they do not actually negotiate SSL 2.0.

tls

TLS servers MUST NOT reply with an SSL 2.0 SERVER-HELLO with a protocol version less than { 0x03, 0x00 }; instead they MUST abort the connection when the highest protocol version offered by the client is { 0x02, 0x00 }.

tls, security

SSL 2.0 handshake messages are not protected, permitting a man-in-the-middle attacker to trick the client into selecting a weaker cipher suite than it would normally choose.

tls, security

SSL 2.0 sessions can be easily terminated by a man-in-the-middle inserting a TCP FIN, and the peer cannot determine whether the session end was legitimate.

tls, security, tcp

SSL 2.0 uses MD5 for message authentication, which is considered cryptographically weak. Most security-aware users have already moved away from any use of MD5.

tls, security, crypto

SSL 2.0 uses the same key for message integrity and message encryption, which is problematic when a weak encryption algorithm is negotiated.

tls, security, crypto