Skip to main content

7. The TLS Handshaking Protocols

The TLS Handshake Protocol is responsible for the following:

  • Negotiating the TLS version and cipher suite
  • Server and client authentication
  • Negotiating encryption parameters and keys
  • Detecting transmission errors

The handshake protocol consists of three sub-protocols:

7.1. Change Cipher Spec Protocol​

The Change Cipher Spec Protocol is used to notify the peer that subsequent records will be protected under the newly negotiated CipherSpec and keys. The protocol consists of a single message, which is encrypted and compressed under the current (not the pending) CipherSpec. The message consists of a single byte of value 1.

struct {
    enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;

The ChangeCipherSpec message is sent during the handshake after the security parameters have been agreed upon. The receiver of a ChangeCipherSpec message MUST update the read pending state to the read current state. A Finished message is sent immediately after this message, using the new algorithms, keys, and secrets. Implementations MUST NOT send ChangeCipherSpec messages until the handshake is complete. The first message received after this message MUST be a Finished message.

7.2. Alert Protocol​

TLS provides Alert messages to convey alerts to peer entities. As with other messages, alert messages are encrypted and compressed using the current connection state.

enum { warning(1), fatal(2), (255) } AlertLevel;

enum {
    close_notify(0),
    unexpected_message(10),
    bad_record_mac(20),
    decryption_failed_RESERVED(21),
    record_overflow(22),
    decompression_failure(30),
    handshake_failure(40),
    no_certificate_RESERVED(41),
    bad_certificate(42),
    unsupported_certificate(43),
    certificate_revoked(44),
    certificate_expired(45),
    certificate_unknown(46),
    illegal_parameter(47),
    unknown_ca(48),
    access_denied(49),
    decode_error(50),
    decrypt_error(51),
    export_restriction_RESERVED(60),
    protocol_version(70),
    insufficient_security(71),
    internal_error(80),
    user_canceled(90),
    no_renegotiation(100),
    unsupported_extension(110),
    (255)
} AlertDescription;

struct {
    AlertLevel level;
    AlertDescription description;
} Alert;

7.2.1. Closure Alerts​

The client and the server MUST share closure information before closing the write side of the connection. Either party may initiate the closure of its connection by sending a close_notify alert. Any party that receives a closure alert MUST immediately cease sending new data over the connection. After transmitting a close_notify, an implementation MUST NOT send any data on that connection.

7.2.2. Error Alerts​

Error handling in the TLS protocol is very simple. When an error is detected, the detecting party sends a message to its peer. Upon transmission or receipt of a fatal alert, both parties MUST immediately close the connection. Servers and clients MUST forget secret values and keys established in failed connections.

The following error alerts are defined:

  • unexpected_message: An inappropriate message was received. This alert should never be observed by properly implemented parties.
  • bad_record_mac: This alert is returned if a record is received with an incorrect MAC. This message is always fatal.
  • record_overflow: A TLSCiphertext record was received that had a length more than 2^14+2048 bytes, or a record decrypted to a TLSCompressed record with more than 2^14 bytes (or some other negotiated limit for the connection state). This message is always fatal.
  • handshake_failure: Reception of a handshake_failure alert message indicates that the sender was unable to negotiate an acceptable set of security parameters given the options available.
  • bad_certificate: A certificate was corrupt, contained signatures that did not verify correctly, etc.
  • unsupported_certificate: A certificate was of an unsupported type.
  • certificate_revoked: A certificate was revoked by its signer.
  • certificate_expired: A certificate has expired or is not currently valid.
  • certificate_unknown: Some other (unspecified) issue arose in processing the certificate, rendering it unacceptable.
  • illegal_parameter: A field in the handshake was out of range or inconsistent with other fields. This message is always fatal.
  • unknown_ca: A valid certificate chain or partial chain was received, but the certificate was not accepted because the CA certificate could not be located or could not be matched with a known, trusted CA.
  • access_denied: A valid certificate was received, but when access control was applied, the sender decided not to proceed with negotiation.
  • decode_error: A message could not be decoded because some field was out of the specified range or the length of the message was incorrect. This message is always fatal.
  • decrypt_error: A handshake cryptographic operation failed, including being unable to correctly verify a signature or validate a Finished message.
  • protocol_version: The protocol version the peer has attempted to negotiate is recognized but not supported.
  • insufficient_security: Returned instead of handshake_failure when a negotiation has failed specifically because the server requires ciphers more secure than those supported by the client.
  • internal_error: An internal error unrelated to the peer or the correctness of the protocol (such as a memory allocation failure) makes it impossible to continue. This message is always fatal.
  • user_canceled: This handshake is being canceled for some reason unrelated to a protocol failure.
  • no_renegotiation: Sent by a client in response to a hello request or by the server in response to a client hello after initial handshaking. This message is always a warning.
  • unsupported_extension: Sent by servers who are unable to understand an extension.

7.3. Handshake Protocol Overview​

The TLS Handshake Protocol involves the following steps:

  • Exchange hello messages to agree on algorithms, exchange random values, and check for session resumption.
  • Exchange the necessary cryptographic parameters to allow the client and server to agree on a premaster secret.
  • Exchange certificates and cryptographic information to allow the client and server to authenticate themselves.
  • Generate a master secret from the premaster secret and exchanged random values.
  • Provide security parameters to the record layer.
  • Allow the client and server to verify that their peer has calculated the same security parameters and that the handshake occurred without being tampered with by an attacker.

Note: This document provides only an overview of the TLS 1.2 handshake protocol. For complete technical details, please refer to Section 7.4 and subsequent sections of RFC 5246.

7.4. Handshake Protocol​

The TLS Handshake Protocol is one of the defined higher-level clients of the TLS Record Layer. This protocol is used to negotiate the security attributes of a connection. Handshake messages are supplied to the TLS record layer, where they are encapsulated within one or more TLSPlaintext structures, which are processed and transmitted as specified by the current active connection state.

enum {
    hello_request(0), client_hello(1), server_hello(2),
    certificate(11), server_key_exchange (12),
    certificate_request(13), server_hello_done(14),
    certificate_verify(15), client_key_exchange(16),
    finished(20), (255)
} HandshakeType;

struct {
    HandshakeType msg_type;
    uint24 length;
    select (HandshakeType) {
        case hello_request:       HelloRequest;
        case client_hello:        ClientHello;
        case server_hello:        ServerHello;
        case certificate:         Certificate;
        case server_key_exchange: ServerKeyExchange;
        case certificate_request: CertificateRequest;
        case server_hello_done:   ServerHelloDone;
        case certificate_verify:  CertificateVerify;
        case client_key_exchange: ClientKeyExchange;
        case finished:            Finished;
    } body;
} Handshake;

Handshake protocol messages are presented with explicit lengths and cannot be fragmented across handshake record boundaries. That is, each handshake message must fit entirely within a single handshake record or span multiple handshake records, each containing an integral number of handshake messages. Receivers MUST check that there is no other data following a handshake message in the same handshake record, unless that data itself constitutes valid handshake messages.

For complete handshake message types and detailed formats, please refer to subsections of Section 7.4 in RFC 5246.

Last updated on