Before your browser loads this page —or any site with a padlock— a silent conversation takes place in a few milliseconds. It is the TLS handshake (TLS, Transport Layer Security: the protocol that encrypts and authenticates nearly all Internet traffic). In its current version, TLS 1.3, that ceremony completes in a single round trip between your machine and the server. This article dissects exactly what gets decided in that exchange and why it is secure.
The problem the handshake solves
To communicate securely, both parties need a session key (the bytes used to encrypt and decrypt each block of data) and must be sure who they are talking to. On a clean channel, agreeing on a key would suffice; but on the Internet an attacker can eavesdrop and also modify messages in transit. The handshake must achieve three things: negotiate the encryption, authenticate the server, and derive a key that nobody else can reconstruct.
Negotiating: the cipher suite and parameters
Everything starts with the ClientHello: the client sends its TLS version, a list of cipher suites (combinations of algorithms, e.g. TLS_AES_128_GCM_SHA256) and its key-exchange data. The server answers with the ServerHello, choosing one suite and providing its own key material. In TLS 1.3 that negotiation was narrowed to a few modern suites: legacy algorithms and the options that added complexity and risk were removed.
Key exchange: ECDHE and the shared secret
The session key never travels over the network; it is built independently at each end. To do this, TLS 1.3 uses ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), a variant of the Diffie-Hellman exchange on elliptic curves. Each party generates a single-use public/private key pair —that is what ephemeral means—, only the public ones are exchanged and, by combining them with their own private key, both derive the same curve point: the same shared secret. An observer who only sees the public keys cannot recompute it (the elliptic-curve discrete logarithm problem).
The key property of ephemeral keys is forward secrecy: because the keys are single-use and discarded, an attacker who captures and decrypts old recorded traffic cannot use it to decrypt future communications, even if they later steal the server’s long-term private key.
Authentication: the certificate and the signature
Both parties computing the same key is not enough: the server must prove it is who it claims to be. The server sends its X.509 certificate (a document digitally signed by a certificate authority, a trusted entity whose seal your operating system or browser verifies). Your machine validates the chain of trust: that the certificate’s signature is correct, that it has not expired, and that the domain matches. Then, in the CertificateVerify step, the server signs the summary of the whole conversation with its long-term private key: only the holder of that key can produce such a signature, closing the loop of authentication.
Deriving keys: HKDF and the transcript hash
With the ECDHE shared secret and the already-exchanged messages, each end derives the actual encryption keys through a HKDF (HMAC-based Key Derivation Function) chain: a function that stretches a low-entropy secret into several independent keys (one to encrypt client-to-server, another for the reverse direction, keys for the finalization messages…). In addition, all handshake messages are chained into a transcript hash: the digest of what was spoken is encrypted, so that if an attacker tried to replay or reorder messages, the resulting keys would differ and the connection would be detected as corrupted.
The two Finished messages and 0-RTT
With the keys ready, each side sends its encrypted Finished message: proof that it knows the correct keys. From then on, data flows encrypted. Overall, TLS 1.3 completes authentication and key establishment in a single round trip (1-RTT), versus two in TLS 1.2. It also offers an optimization called 0-RTT (zero round trip): with a resumption ticket issued by the server, a reconnection can send data in the very first message, without waiting to finish the handshake —at the cost of giving up part of the authenticated protection.
Why it matters
TLS 1.3’s handshake is not just a protocol: it is the cryptographic foundation of the modern web. Understanding its pieces —constrained negotiation, ephemeral ECDHE, X.509 certificates, and HKDF derivation with a transcript hash— lets you reason about why a connection “is secure” and what each step of the process protects (and what it does not). Next time you see the padlock in the address bar, you will know that behind it there is a four-message cryptographic choreography designed so that not even the server owner can spy on a future session.
