Detailed Explanation of the SSL/TLS Handshake Process in HTTPS

Detailed Explanation of the SSL/TLS Handshake Process in HTTPS

1. Background and Purpose
HTTPS adds an SSL/TLS layer on top of HTTP to ensure communication security through encryption and authentication. The handshake process is the core of establishing a secure connection, requiring negotiation of encryption parameters, verification of server identity (and optionally client identity), and generation of session keys. The following explanation uses TLS 1.2 as an example, breaking it down step by step.

2. Detailed Handshake Process
Step 1: ClientHello (Client Initiates Request)
The client sends to the server:

  • Supported TLS version (e.g., TLS 1.2).
  • Client Random: Used for subsequent key generation.
  • List of supported cipher suites (Cipher Suites), e.g., TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, which includes key exchange algorithm, encryption algorithm, and hash algorithm.
  • Compression method (optional, usually disabled in modern TLS).
  • Session ID (if session resumption is desired).

Step 2: ServerHello (Server Responds with Negotiation)
The server replies with:

  • Selected TLS version (the highest version supported by both parties).
  • Server Random: Used together with Client Random to generate keys.
  • Selected cipher suite (e.g., ECDHE_RSA).
  • Session ID (if session resumption is supported).

Step 3: Server Certificate (Authentication)
The server sends a digital certificate chain, containing:

  • Server public key: Used for subsequent key exchange (e.g., RSA public key).
  • Certificate Authority (CA) signature: The client verifies the certificate's authenticity using pre-installed CA root certificates.

Step 4: ServerKeyExchange (Key Exchange Parameters, required only for certain algorithms)
If using ephemeral key exchange algorithms like ECDHE, the server sends:

  • Elliptic curve parameters (e.g., named curve secp256r1).
  • Server ephemeral public key (Server Params), used to generate the pre-master secret.

Step 5: ServerHelloDone
The server notifies the client that the initial negotiation messages have been sent.

Step 6: Client Verifies Certificate
The client checks:

  • Whether the certificate is issued by a trusted CA.
  • Whether the certificate is within its validity period.
  • Whether the domain name matches.
    If verification fails, the connection is terminated.

Step 7: ClientKeyExchange (Client Key Exchange)
The client generates:

  • Pre-Master Secret, encrypted with the server's public key (in RSA scheme) or generated based on the server's ephemeral public key (in ECDHE scheme).
  • Sends the encrypted pre-master secret or the client's ephemeral public key (Client Params).

Step 8: Key Generation
Both parties use the Client Random, Server Random, and Pre-Master Secret to generate, via a PRF (Pseudo-Random Function):

  • Master Secret → Further derives session keys (encryption key, MAC key, initialization vector).

Step 9: ChangeCipherSpec (Switch to Encrypted Mode)
The client sends this message, indicating that subsequent communication will be encrypted using the negotiated keys.

Step 10: Finished (Handshake Completion Verification)
The client sends an encrypted Finished message containing a hash of all previous handshake messages for the server to verify integrity. The server similarly replies with ChangeCipherSpec and Finished messages. After both parties successfully verify, the secure channel is established.

3. Session Resumption Optimization
To reduce handshake overhead, TLS supports session resumption:

  • Session ID: The server stores session parameters, and the client uses the ID to resume the session in the next connection.
  • Session Ticket: The server encrypts session parameters and sends them to the client, who submits the Ticket in the next connection to resume the session.

4. Key Security Features

  • Forward Secrecy: When using ephemeral key exchange algorithms like ECDHE, even if the server's private key is compromised, past sessions cannot be decrypted.
  • Tamper Resistance: The Finished message verifies that the handshake process has not been tampered with.
  • Authentication: The certificate mechanism ensures the client communicates with a legitimate server.