Skip to main content

Appendix E. Backward Compatibility

This appendix discusses compatibility issues between TLS 1.2 and earlier versions.

E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0​

Due to new features and some structural changes, there is no direct interoperability between TLS 1.2 and TLS 1.1, TLS 1.0, and SSL 3.0. However, TLS 1.2 contains a mechanism by which a TLS 1.2 implementation can negotiate with earlier versions.

E.1.1. Version Negotiation​

TLS provides a built-in mechanism for version negotiation as part of the handshake:

  1. Version in ClientHello:

    • The client indicates the highest version it supports in the ClientHello
    • Implementations SHOULD indicate TLS 1.2 (version \{3, 3\}) in the ClientHello

  2. Version in ServerHello:

    • The server selects the highest version supported by both itself and the client
    • If the server does not support the version suggested by the client, it selects a lower version

  3. Record Layer Version:

    • The version of the ClientHello record SHOULD be set to \{3, 1\} (TLS 1.0) for maximum compatibility
    • Subsequent records use the negotiated version

E.1.2. Extensions​

TLS 1.2 introduces new extensions and changes to existing extensions:

  • signature_algorithms extension: TLS 1.2 clients MUST include this extension
  • Servers of older versions will ignore extensions they do not understand

E.1.3. Cipher Suites​

Certain cipher suites are specific to TLS 1.2:

  • Cipher suites using the SHA-256 PRF
  • New AEAD cipher suites

When negotiating with earlier versions, these cipher suites SHOULD NOT be offered in the ClientHello.

E.1.4. Implementation Recommendations​

Client implementations SHOULD:

  • Support multiple TLS versions
  • Announce the highest supported version in ClientHello
  • Be prepared to accept a lower version
  • Implement version fallback protection (SCSV)

Server implementations SHOULD:

  • Support multiple TLS versions for broad compatibility
  • Prefer the highest protocol version
  • Properly handle ClientHellos from earlier versions

Example Negotiation Flow:

Client (supports TLS 1.2, 1.1, 1.0)
  -> ClientHello (version=3.3)
     Supported versions: TLS 1.2, 1.1, 1.0

Server (supports only TLS 1.1, 1.0)
  <- ServerHello (version=3.2)
     Selected: TLS 1.1

Connection continues using TLS 1.1

E.2. Compatibility with SSL 2.0​

SSL 2.0 SHOULD NOT be used in new implementations. However, for compatibility with legacy systems, some implementations may need to understand SSL 2.0-format ClientHellos.

E.2.1. SSL 2.0 ClientHello​

The SSL 2.0 ClientHello has a different format:

uint16 msg_length;          /* Highest bit MUST be 1 */
uint8 msg_type;             /* MUST be 1 */
Version version;            /* Version desired by client */
uint16 cipher_spec_length;  /* Cannot be 0 */
uint16 session_id_length;   /* MUST be 0 or 16 */
uint16 challenge_length;    /* Cannot be 0 */
CipherSpec cipher_specs[...];
SessionID session_id;
Challenge challenge;

E.2.2. Handling SSL 2.0 ClientHello​

A TLS 1.2 server MAY accept a ClientHello encapsulated in SSL 2.0 format, but MUST:

  1. Check the highest bit of msg_length
  2. Verify format validity
  3. Convert it to TLS format for processing
  4. Respond with a TLS-format ServerHello

E.2.3. Security Considerations​

Important: Supporting SSL 2.0-format ClientHellos does not mean supporting the SSL 2.0 protocol itself. SSL 2.0 has many known security vulnerabilities and MUST NOT be negotiated for use.

E.2.4. Implementation Recommendations​

  • TLS 1.2 clients MUST NOT send SSL 2.0-format ClientHellos
  • Server support for SSL 2.0-format ClientHellos is now MAY, rather than SHOULD
  • Sending SSL 2.0-format ClientHellos is SHOULD NOT
  • Future TLS versions may change this to SHOULD NOT support

E.3. Avoiding Man-in-the-Middle Version Rollback​

Earlier versions of the protocol were vulnerable to version rollback attacks where an attacker could force a connection to use an earlier (weaker) protocol version.

E.3.1. Protection Mechanisms​

TLS 1.2 uses multiple mechanisms to prevent version rollback:

  1. Finished Message Verification:

    • The Finished message contains a hash of all handshake messages
    • Includes the version fields from ClientHello and ServerHello
    • Any version modification will cause Finished verification to fail

  2. TLS_FALLBACK_SCSV:

    • Signaling Cipher Suite Value defined in RFC 7507
    • Clients include this value when retrying a connection with a lower version
    • Server rejects the connection if it supports a higher version

E.3.2. Implementation Requirements​

Clients MUST:

  • Record previously attempted versions
  • Include TLS_FALLBACK_SCSV when downgrading retry
  • Verify Finished message

Servers MUST:

  • Check for TLS_FALLBACK_SCSV
  • Send inappropriate_fallback alert if a higher version is supported
  • Correctly compute and verify Finished message

E.3.3. Example Scenarios​

Normal Connection:

Client -> ClientHello (TLS 1.2)
Server <- ServerHello (TLS 1.2)
... Normal handshake ...
Success!

Legitimate Downgrade:

Client -> ClientHello (TLS 1.2)
Server <- ServerHello (TLS 1.1)
... TLS 1.1 handshake ...
Success!

Detected Attack:

Client -> ClientHello (TLS 1.2)
Attacker modifies to (TLS 1.0)
Server <- ServerHello (TLS 1.0)
... Handshake continues ...
Client -> Finished (verification fails!)
Connection aborted!

Retry with SCSV:

Client -> ClientHello (TLS 1.2) - Fails
Client -> ClientHello (TLS 1.1, TLS_FALLBACK_SCSV)
Server detects SCSV and supports TLS 1.2
Server <- Alert: inappropriate_fallback
Connection aborted - Downgrade attack detected!

Note: For complete compatibility information and detailed explanations, please refer to the full text of RFC 5246 Appendix E.