SSL8 min read

HTTPS Handshake Explained: How TLS Connections Work

The TLS handshake establishes a secure encrypted channel between a browser and server before any data is transferred. Understanding it helps diagnose SSL errors and performance issues.

Every HTTPS connection begins with a TLS handshake — a brief negotiation between the browser and server that establishes which encryption algorithms to use, verifies the server's identity through its certificate, and creates the shared encryption keys for the session. Understanding this process helps you diagnose SSL errors, optimize connection performance, and understand what "secure" really means.

What Is the TLS Handshake?

The TLS handshake (formerly called the SSL handshake) is the protocol that runs before any encrypted data is exchanged. It serves three purposes:

  1. Authentication: The server proves its identity to the browser by presenting a digital certificate signed by a trusted Certificate Authority (CA).
  2. Key exchange: Both parties generate shared session keys without transmitting them directly over the network.
  3. Algorithm negotiation: The browser and server agree on which cipher suite (encryption algorithm) to use for the session.

TLS 1.2 Handshake: Step by Step

TLS 1.2 (still common on older servers) requires two round trips between client and server before data can flow:

text
Client Server | | |------- ClientHello ----------------->| Step 1 | | |<------ ServerHello ------------------| Step 2 |<------ Certificate ------------------| |<------ ServerKeyExchange ------------| |<------ ServerHelloDone -------------| | | |------- ClientKeyExchange ----------->| Step 3 |------- ChangeCipherSpec ------------>| |------- Finished -------------------->| | | |<------ ChangeCipherSpec -------------| Step 4 |<------ Finished --------------------| | | |======= Encrypted Data ============== | Application data

Step 1: ClientHello

The browser initiates the handshake by sending a ClientHello message containing:

  • TLS version(s) it supports.
  • A random number (Client Random) used later in key derivation.
  • A list of cipher suites it supports (e.g., TLS_AES_256_GCM_SHA384).
  • The SNI (Server Name Indication) extension — the hostname being requested, so servers hosting multiple domains can return the correct certificate.

Step 2: ServerHello, Certificate, and Key Exchange

The server responds with:

  • ServerHello: The chosen TLS version, a Server Random number, and the selected cipher suite.
  • Certificate: The server's SSL/TLS certificate, signed by a CA. The browser verifies this against its built-in list of trusted CAs.
  • ServerKeyExchange: For cipher suites using Diffie-Hellman key exchange, the server sends its DH public key.
  • ServerHelloDone: Signals that the server's part is complete.

Step 3: Client Key Exchange and Finished

The browser verifies the certificate, then:

  • Generates the session key material using the exchanged parameters (Client Random + Server Random + shared DH output).
  • Sends a ChangeCipherSpec message to signal that subsequent messages will be encrypted.
  • Sends a Finished message — the first encrypted message, containing a hash of the handshake transcript.

Step 4: Server Finished

The server also sends ChangeCipherSpec and Finished messages. Once both sides have verified each other's Finished message, the handshake is complete and application data (HTTP request/response) begins to flow.

TLS 1.3 Handshake: Faster and More Secure

TLS 1.3 (finalized in 2018) redesigned the handshake to require only one round trip — cutting connection setup time roughly in half. It also removed support for legacy weak cipher suites.

text
Client Server | | |------- ClientHello ----------------->| Round Trip 1 | + Key Share | | + Supported Versions | | | |<------ ServerHello ------------------| |<------ Encrypted Extensions ---------| |<------ Certificate ------------------| |<------ CertificateVerify ------------| |<------ Finished --------------------| | | |------- Finished -------------------->| Round Trip 2 | | |======= Encrypted Data ============== | Application data

In TLS 1.3, the client includes its key share in the ClientHello, allowing the server to derive session keys immediately and begin encrypting data in its first response — before the handshake is fully complete.

0-RTT Resumption: Zero Round-Trip Reconnection

TLS 1.3 also supports 0-RTT (Zero Round-Trip Time) resumption for repeat connections. If the client has a session ticket from a previous connection, it can send encrypted application data immediately alongside the ClientHello, before any response from the server.

0-RTT security trade-off0-RTT improves performance but introduces a risk of replay attacks — an attacker could replay the initial data. For this reason, 0-RTT should only be used for idempotent requests (like GET requests) and not for requests that trigger state changes.

Certificate Verification

During the handshake, the browser verifies the server's certificate by checking:

  • The certificate is signed by a CA in the browser's trust store.
  • The certificate has not expired (notBefore and notAfter dates).
  • The certificate's Common Name or Subject Alternative Names (SANs) match the hostname being accessed.
  • The certificate has not been revoked (checked via OCSP or CRL).
  • The certificate chain is complete — each certificate in the chain is signed by the one above it, up to a trusted root CA.

You can inspect a server's certificate with the ShowDNS SSL Checker.

Cipher Suites

A cipher suite defines the combination of algorithms used for key exchange, authentication, encryption, and integrity checking. A TLS 1.3 cipher suite looks like:

text
TLS_AES_256_GCM_SHA384 │ │ │ │ │ │ │ └── Hash algorithm (SHA-384 for integrity/PRF) │ │ └────────── Cipher mode (GCM = Galois/Counter Mode) │ └─────────────────── Symmetric cipher (AES-256) └─────────────────────── Protocol (TLS)

Common TLS Handshake Errors

ErrorCauseFix
SSL_ERROR_HANDSHAKE_FAILURENo common cipher suiteUpdate server to support modern cipher suites
ERR_CERT_DATE_INVALIDCertificate expired or clock mismatchRenew certificate; check system clock
ERR_CERT_AUTHORITY_INVALIDCertificate signed by untrusted CAUse a publicly trusted CA; send complete chain
ERR_CERT_COMMON_NAME_INVALIDHostname mismatchEnsure certificate covers the requested domain

Frequently Asked Questions

How long does the TLS handshake take?

The TLS 1.2 handshake adds two round trips before data can flow. At 50ms round-trip time, that is 100ms of latency overhead. TLS 1.3 reduces this to one round trip (50ms). 0-RTT eliminates the handshake latency entirely for repeat connections.

What is SNI and why does it matter?

Server Name Indication (SNI) is an extension to the TLS ClientHello that tells the server which hostname the client is trying to reach. This allows one server with one IP address to host multiple HTTPS sites with different certificates. Without SNI, a server with multiple domains could only present one certificate.

Does TLS 1.3 work with all browsers?

Yes. TLS 1.3 is supported by all modern browsers including Chrome, Firefox, Safari, and Edge. It has been the recommended standard since 2018.

Related Articles