TLS and HTTPS: Handshakes and Certificates
How HTTPS blocks eavesdropping and tampering through key exchange, certificate validation, and encryption, explained against TLS 1.2 and 1.3.
Contents
HTTPS wraps HTTP in TLS so that keys are agreed on safely and certificates confirm that the server on the other end is genuine.
The threats HTTPS blocks
With plaintext HTTP, anyone on the path can read and alter the content. Every hop a packet passes through, from public Wi-Fi to carrier equipment, is a potential eavesdropping point. HTTPS handles this by wrapping HTTP messages in Transport Layer Security (TLS). TLS descends from the Secure Sockets Layer (SSL), and TLS is the standard today.
The properties TLS aims to guarantee break into three. Confidentiality blocks eavesdropping, integrity detects tampering, and authentication confirms that the other party is not an impostor. RFC 8446 defines the purpose of TLS 1.3 as preventing eavesdropping, tampering, and forgery.
The division of labor between symmetric and asymmetric keys
Symmetric key cryptography encrypts and decrypts with the same key. It is fast, but both sides have to share that key in advance. Asymmetric key cryptography locks with a public key and unlocks only with the private key, which makes it possible to hand over a key safely. The downside is that the computation is heavy and unsuited to bulk data.
TLS divides the two within a single connection. The handshake stage agrees on a session key using asymmetric operations, and the actual data afterward is encrypted with the fast symmetric key.
As the diagram shows, this hybrid approach gets the safety of the key exchange and the speed of the transfer together.
The TLS 1.2 handshake
A full handshake takes two round trips (RTT). The messages travel in the following order.
In ClientHello and ServerHello, the two sides exchange supported cipher suites and random values. The server also sends its certificate, and the client validates it. The client then creates a pre-master secret, encrypts it with the server public key, and sends it over. Finally both sides derive the same session key from the two random values and the pre-master secret.
Once the session key exists, the Finished message confirms that the handshake was not tampered with. Every HTTP byte after that is encrypted with this symmetric session key. This procedure follows RFC 5246, which defines TLS 1.2.
Certificates and the chain of trust
A server certificate binds a domain to a public key and is signed by a certification authority (CA). The format follows the X.509 standard, and RFC 5280 defines the certificate and revocation list profiles. The client validates signatures along the chain that runs from the server certificate through intermediate certificates to the root certificate. Root certificates live in the trust store built into the operating system or the browser.
Validation is not only about signatures. It also checks that the domain name matches the certificate subject and that the validity period has not passed.
| Check | What is verified | On failure |
|---|---|---|
| Signature chain | The parent signature is verified with the CA public key | Untrusted issuer |
| Domain match | The connected hostname is compared to the certificate subject | Hostname mismatch warning |
| Validity period | The current time is before expiry | Certificate expired error |
Even with encryption in place, weak certificate validation leaves the connection open to a man-in-the-middle attack. The safety of TLS therefore rests on server authentication as much as on encryption.
Encryption and integrity
Confidentiality alone does not stop tampering. An attacker who cannot read the content can still manipulate the ciphertext. To prevent that, TLS also checks integrity with a message authentication code (MAC) or an authentication tag.
Modern TLS uses authenticated encryption with associated data (AEAD). AEAD folds encryption and the integrity check into a single operation and discards the message when the authentication tag does not match on decryption. RFC 8446 mandates AEAD only in TLS 1.3, and AES-GCM is the representative example.
What changed in TLS 1.3
TLS 1.3 shortened the handshake and removed the weak options. The full handshake drops to 1-RTT, and 0-RTT resumption reusing information from a previous connection is also possible. The largest change is the removal of static RSA key transport, leaving only ephemeral (EC)DHE exchange.
ECDHE here means Elliptic Curve Diffie-Hellman Ephemeral key exchange. Because a fresh ephemeral key is generated for every session, forward secrecy is guaranteed. Forward secrecy is the property that past sessions cannot be decrypted even if the server private key leaks later.
| Item | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Full handshake | 2-RTT | 1-RTT |
| Session resumption | Session tickets (limited) | PSK-based 0-RTT |
| Key exchange | RSA, DH, ECDHE, and others | (EC)DHE only |
| Forward secrecy | Optional | Mandatory |
The table entries are based on RFC 8446 (TLS 1.3) and RFC 5246 (TLS 1.2). TLS 1.3 defines five cipher suites, all of them AEAD-based.
What to check in operations
In practice, TLS problems usually come from expired certificates, missing chains, name mismatches, or the termination point. From the command line, openssl checks the handshake and the certificate directly.
# Inspect the certificate chain and handshake (with SNI)
openssl s_client -connect example.com:443 -servername example.com
# Negotiate TLS 1.3 only to check compatibility
openssl s_client -connect example.com:443 -tls1_3The -servername option here sets Server Name Indication (SNI). When one IP hosts several domains, the server reads SNI to pick the right certificate.
The other thing to check is where TLS terminates. If a load balancer or CDN ends TLS, the internal hop behind it may be plaintext. Where required, protect that hop with re-encryption or mutual TLS (mTLS).
TLS covers confidentiality and integrity in transit. Adding HTTP Strict Transport Security (HSTS) on top forces HTTPS connections. HSTS carries its policy in the Strict-Transport-Security response header and is specified by RFC 6797. Application-level security such as XSS or session hijacking, however, is the job of separate header, token, and cookie policies rather than TLS.
Summary
HTTPS wraps HTTP in TLS to provide confidentiality, integrity, and authentication together. The handshake agrees on a session key with asymmetric operations, and the traffic afterward is encrypted with a fast symmetric key, a hybrid structure. Trust begins with certificate validation that checks the CA chain, the domain, and the validity period. When that validation is weak, encryption alone still falls to a man-in-the-middle attack.
TLS 1.3 cut the handshake to 1-RTT and left only ephemeral key exchange, making forward secrecy the default. In operations, use openssl to check the chain and the version, and cover the internal hop behind the TLS termination point as well.