SSLv3 cannot be patched to fix its CBC, key exchange, or primitive flaws because the available correction mechanisms (extensions, renegotiation indication, encrypt-then-MAC) were all introduced as TLS extensions, a feature SSLv3 does not support. This structural limitation makes deprecation the only viable path.

tls, security

SSLv3 is unable to use ClientHello extensions and therefore cannot benefit from AEAD modes, ECDH/ECDSA, stateless session tickets, DTLS, or ALPN — all significant capabilities added in TLS 1.0 and later. Even new cipher suites cannot compensate for the absence of modern cryptographic modes.

tls

This document updates the backward compatibility section of RFC 5246 and its predecessors (RFC 2246, RFC 4346) to prohibit fallback to SSLv3, overriding prior guidance that permitted negotiation of older protocol versions for compatibility.

tls

TLS specifications were historically unclear about what value TLSPlaintext.version could contain when sending ClientHello. RFC 5246 Appendix E permits selecting the record layer version to maximize interoperability; servers must therefore accept any {03,XX} record layer version for ClientHello even though SSLv3 negotiation itself is forbidden.

tls

Any party receiving a Hello message with protocol version set to {03,00} MUST respond with a 'protocol_version' alert message and close the connection.

tls, security

Clients MUST NOT send a ClientHello with ClientHello.client_version set to {03,00}.

tls, security

Servers MUST NOT send a ServerHello with ServerHello.server_version set to {03,00}.

tls, security

SSLv3 MUST NOT be used. Negotiation of SSLv3 from any version of TLS MUST NOT be permitted.

tls, security

TLS servers MUST accept any value {03,XX} (including {03,00}) as the record layer version number for ClientHello, but they MUST NOT negotiate SSLv3.

tls

RC4 is the only stream cipher defined in SSLv3 that remains in widespread use, but RC4 exhibits serious biases and is no longer fit for use (RFC 7465). This leaves SSLv3 with no suitable record protection mechanism.

tls, security, crypto

SSLv3 defines custom constructions for PRF, HMAC, and digital signatures that lack the cryptographic scrutiny of standard TLS constructions. All SSLv3 primitives rely on SHA-1 and MD5, which are considered weak and are being replaced with stronger hash functions such as SHA-256.

tls, security, crypto

The non-deterministic padding used in the CBC construction of SSLv3 trivially permits recovery of plaintext (POODLE attack). The CBC modes use a flawed MAC-then-encrypt construction that cannot be corrected in SSLv3 because the fix relies on TLS extensions, a feature SSLv3 lacks.

tls, security, crypto

The SSLv3 key exchange is vulnerable to man-in-the-middle attacks when renegotiation (RFC 5746) or session resumption (Triple Handshake attack) are used. Both flaws were fixed in TLS via extensions that SSLv3 cannot adopt.

tls, security, crypto