PQC Toolbox

PROTOCOL FIELD GUIDE

How TLS works

When you open an HTTPS website, your browser and the server agree on keys, prove the server’s identity and protect the data they exchange. Each step answers a different security question.

ILLUSTRATED EXAMPLE

A TLS 1.3 handshake

This example shows a typical first HTTPS connection with a server certificate. Each row is a protocol step. Several server messages can travel together, so the seven rows do not mean seven round trips. Once TCP is connected, the browser can usually send its first HTTP request after one TLS round trip.

BrowserWeb server
  1. Step 1 · Browser → Server

    Offer a connection

    ClientHello

    The browser offers TLS versions, cipher suites, signature algorithms and key shares. The server can choose only a combination both sides support.

    Exposure. A network observer can usually see the initial hello, including the hostname unless Encrypted Client Hello protects it. Separate legacy probes reveal what an older client can negotiate.

  2. Step 2 · Server → Browser

    Establish a shared secret

    ServerHello

    The server selects a TLS version and cipher suite and sends its key share. Each side now has the information it needs to derive the handshake keys.

    Exposure. With classical X25519 alone, an attacker could record traffic today and recover the secret with a sufficiently capable future quantum computer. The hybrid group X25519MLKEM768 combines classical X25519 with post-quantum ML-KEM to protect against that scenario.

  3. Step 3 · Server → Browser

    Confirm connection options

    EncryptedExtensions

    The server sends additional negotiated options under the handshake keys. A passive observer can still see record sizes and timing.

  4. Step 4 · Server → Browser

    Authenticate the website

    Certificate + CertificateVerify

    The server sends its certificate chain and signs the handshake transcript with its private key. The browser checks the chain, validity dates and hostname, then verifies the live signature using the website’s certified public key.

    Exposure. A stolen server key or a certificate issued to an impostor can enable impersonation. RSA and ECDSA signatures also face a future quantum forgery threat, even when the connection uses hybrid key exchange.

    Certificate signing · who vouched for this key?

    The issuer signed the certificate when it was issued. In the checker, an ECDSA or RSA issuer signature is classical. A hybrid key exchange can protect the session secret while the certificate still relies on classical signatures to establish identity.

    Handshake signing · who holds the key now?

    The server signs the current handshake with the private key corresponding to its certificate. Read the Handshake signing result to see which algorithm authenticated this connection. It can differ from the algorithm the issuer used to sign the certificate.

  5. Step 5 · Server → Browser

    Confirm the server’s handshake

    Finished

    The server sends a value computed from its handshake secret and the messages exchanged so far. The browser computes the value independently. A match confirms that both sides derived the expected secret and saw the same handshake.

    Exposure. Changing an earlier offer in transit makes verification fail. A peer can still legitimately accept a weak configuration it has enabled.

  6. Step 6 · Browser → Server

    Confirm the browser’s handshake

    Finished

    The browser sends its own keyed value over the transcript, now including the server’s Finished message. The server checks it to confirm the browser derived the expected secret. This example uses a website certificate only, so the browser supplies no client certificate.

  7. Step 7 · Browser ↔ Server

    Carry application data

    Application Data

    The server can send application data after sending its own Finished, even before the browser’s Finished arrives. Application traffic uses separate keys in each direction. An authenticated cipher such as AES-GCM protects HTTP requests and responses and detects modifications.

    Exposure. A network observer can still see timing and approximate sizes. Plaintext is accessible where TLS terminates, such as a CDN edge. The edge-to-origin connection has its own security settings.

Explore a site's handshake in the Website Checker →

How to read a checker result

Read these four fields together to see how one TLS 1.3 connection protects traffic and establishes identity.

Example connection · four checker fields
Report fieldExampleWhat it tells you
Key exchangeX25519MLKEM768Hybrid protection for the shared secret. Look here for resistance to recorded traffic being decrypted later.
Website certificate signingECDSA with SHA-256A classical issuer signature. The certificate still relies on classical authentication.
Handshake signingecdsa_secp256r1_sha256The website used its own key to sign this handshake. This is a classical signature.
Connection (traffic cipher)TLS_AES_128_GCM_SHA256AES-128-GCM encrypts and authenticates the records. Read Key exchange to see whether the session used a hybrid group.

Reading this example. Hybrid key exchange protects the session secret. The issuer used a classical signature on the website certificate, and the website used a classical signature to authenticate this handshake.

What changes on a return visit?

A browser can resume a previous session using a ticket, so a fresh certificate exchange may be omitted. If both sides enable 0-RTT, the browser can also send early data before the handshake finishes. An attacker may replay early data, which matters for requests that change state, such as placing an order.

Run the Website Checker → · Inspect a certificate chain →

Protocol references: TLS 1.3 specification · NIST ML-KEM standard