What HTTPS protects
The TLS handshake
Before a single byte of a web page is sent, the client and server carry out a negotiation known as a handshake. It lasts just a few milliseconds and achieves a great deal.
The process, version 1.3
Client (server)
|--- ClientHello + key_share -------->|
|<-- ServerHello + key_share ---------|
|<-- Certificate ---------------------|
|<-- CertificateVerify ---------------|
|<-- Finished ------------------------|
|--- Finished ----------------------->|
|===== (application data) =======>|
Step by step:
- ClientHello: the browser announces the versions and algorithms it accepts, and includes its part of the key exchange;
- ServerHello: the server selects from the proposals and includes its own part. At this point, both parties can already calculate the session key using Diffie-Hellman;
- Certificate: the server presents its certificate, which links its domain name to its public key;
- CertificateVerify: it signs the exchange with its private key. This is the crucial step — it proves that the server actually possesses the certificate’s private key, and not merely a copy of it;
- Finished: each party confirms that the entire dialogue has been received without alteration.
Why CertificateVerify is essential
A certificate is a public document. Anyone can copy a bank’s certificate. Without the CertificateVerify signature, an imposter could present this stolen certificate and pass themselves off as the bank.
It is the signature that makes the difference, as it requires the private key — the one that never leaves the server. This is where the defence against man-in-the-middle attacks comes into play.
The benefits of version 1.3
TLS 1.2 required two round trips before transmitting any data. TLS 1.3 now requires only one, by sending the key exchange portion in the very first message.
Version 1.3 has also cleaned up the standard: outdated or vulnerable algorithms have been removed from the standard rather than left as options. A dangerous option always ends up being enabled somewhere.

