What TLS protects, and where it fits
By the end of this module you will be able to:
- Describe the TLS 1.3 handshake, certificate chain validation, and what TLS actually protects
- Explain forward secrecy, mTLS, and certificate transparency
- Diagnose common TLS errors by matching symptom to root cause
Real-world vulnerability · April 7, 2014
Heartbleed: a memory leak in the TLS library that protected half the internet
On April 7, 2014, researchers at Codenomicon and Google Security disclosed CVE-2014-0160, a memory buffer over-read bug in the OpenSSL implementation of the TLS heartbeat extension. The vulnerability was named Heartbleed.
The heartbeat extension allows a TLS peer to send a small "I am still here" message and get a copy echoed back. The vulnerable code did not validate that the reply length field matched the actual data length. An attacker could claim they sent 64 KB of data when they sent 1 byte. OpenSSL would copy 64 KB from process memory and send it back, exposing whatever happened to be there: private keys, session tokens, passwords, plaintext contents.
Heartbleed illustrates a critical boundary. TLS protects data in transit between the two endpoints. It does not protect against bugs in the implementation of those endpoints. A vulnerability in the TLS library itself can expose everything TLS was designed to protect, without the attacker breaking any cryptographic primitive. Implementation quality is a separate concern from protocol design.
TLS was protecting the connection. The certificate was valid. The handshake completed. Encryption was in place. Yet private keys, passwords, and session tokens were being leaked in plaintext. How is that possible?
TLS placement differs between TCP and QUIC paths
TLS protects application bytes, but the layer arrangement is different for HTTP/2 and HTTP/3.
TLS protects the same bytes in both stacks. The difference is round trips: TCP plus TLS 1.3 needs 2 RTT to first encrypted byte; QUIC integrates TLS into one handshake and reaches 1 RTT, or 0 RTT on repeat.
TLS protects the channel, not every system risk
Confidentiality, integrity, and authentication are channel properties with clear limits.
TLS gives confidentiality, integrity, and server identity for bytes in transit. It does not stop a buggy endpoint from leaking keys, nor does it certify that the server you reached deserves your trust.
14.1 Where TLS sits in the stack
TLS (Transport Layer Security), defined in RFC 8446 for version 1.3, sits between the transport layer and the application layer in the common HTTPS over TCP case. The application sends data to TLS. TLS encrypts and authenticates it. TCP carries the ciphertext.
In HTTP/3, TLS 1.3 is integrated into the QUIC handshake. The cryptographic handshake is not separate from the transport handshake. This means QUIC achieves an encrypted connection in fewer round trips than TCP plus TLS 1.3 separately.
TLS provides three properties once the handshake completes. Confidentiality: the data is encrypted and not readable by observers. Integrity: data cannot be modified in transit without detection. Authentication: one or both peers prove their identity via certificates. The most common case authenticates the server only. mTLS (mutual TLS) authenticates both peers.
TLS also has a metadata boundary. TLS 1.3 encrypts the certificate after the early handshake, but many deployments still expose the intended hostname in SNI. Encrypted Client Hello, defined in RFC 9849, can hide the real ClientHello and SNI when the client, DNS, and server deployment all support it.
With TLS placed in the stack, the next question is what actually happens during the handshake and how those events translate to the latency you observe.
14.2 The TLS 1.3 handshake
TLS 1.3 reduced the handshake to one round trip (1-RTT). The client sends a ClientHello with supported cipher suites and key share data. The server responds with a ServerHello, its key share, a certificate, and a certificate verify message in a single flight. After the client validates the certificate and verifies the server's signature, the handshake is complete and application data can flow.
TLS 1.2 required two round trips for a full handshake. The reduction to 1-RTT in TLS 1.3 was achieved partly by removing insecure cipher suites that required additional negotiation messages and by making key exchange part of the initial hello.
For repeat connections, TLS 1.3 supports 0-RTT (zero round-trip) resumption using a pre-shared session ticket. The client can send application data in the first message, before the handshake completes. This is fast but has a replay caveat: 0-RTT data is vulnerable to replay attacks, so it should only be used for requests that are safe to replay (GET requests, not POST requests with side effects).
The handshake establishes keys, but it also carries the certificate that allows the client to verify who it is talking to. That verification process is where many TLS errors originate.
14.3 Certificates and certificate chain validation
A TLS certificate binds a public key to an identity (a hostname) and is signed by a certificate authority (CA). When a client receives a server's certificate, it validates the chain: the certificate was signed by an intermediate CA, which was signed by a root CA that the client's trust store considers authoritative.
Validation checks include: the hostname in the certificate matches the hostname in the request (Subject Alternative Names), the certificate has not expired, the certificate has not been revoked (checked via CRL or OCSP), and the cryptographic signature is valid.
Certificate Transparency (CT) adds public, append-only audit logs for certificate issuance. RFC 6962 defined the original experimental CT design; RFC 9162 defines Certificate Transparency Version 2.0. Browser and certificate authority policies are what turn CT from a logging mechanism into a deployment requirement for public web certificates. CT allows domain owners and security researchers to detect misissued certificates.
Validated certificates prove identity. Forward secrecy determines whether past sessions remain protected if those certificates are later compromised.
14.4 Forward secrecy and cipher suites
Forward secrecy (more precisely, forward secrecy is sometimes called perfect forward secrecy or PFS) means that the compromise of long-term keys does not expose past session recordings. TLS 1.3 requires forward secrecy. Every handshake uses ephemeral key exchange (ECDHE, elliptic curve Diffie-Hellman ephemeral), meaning a fresh key pair is generated for each session and discarded afterwards.
TLS 1.2 allowed non-forward-secret cipher suites using RSA key exchange. If an attacker recorded encrypted TLS 1.2 traffic and later obtained the server's private key, they could decrypt all recorded sessions. TLS 1.3 removes this risk by mandating ephemeral key exchange.
mTLS (mutual TLS) is TLS where both the client and server present certificates. The server validates the client certificate, not just the server certificate. This is used for service-to-service authentication in internal systems and API authentication where you want cryptographic proof of caller identity.
Common misconception
“HTTPS means the site is safe.”
HTTPS means the connection between your browser and the server is encrypted and the server's identity was verified by a certificate authority. It says nothing about whether the server is trustworthy, the content is safe, the application has been developed securely, or the operator's intentions are legitimate. Phishing sites commonly use HTTPS with valid certificates. Safety involves many factors beyond transport encryption.
A user sees a 'certificate not trusted' warning. The certificate is valid and not expired. What could cause this?
A TLS 1.3 connection was established in 2024. In 2026, the server's private key is compromised. Can an attacker decrypt the 2024 session recordings?
An internal microservice needs to ensure that only authorised client services can call its API, with cryptographic proof of identity. Which TLS feature is appropriate?
Core distinctions
- TLS provides confidentiality, integrity, and authentication for data in transit. It does not protect against vulnerabilities in the endpoint's implementation, as Heartbleed demonstrated.
- TLS 1.3 completes the handshake in one round trip and mandates forward secrecy via ephemeral key exchange. Past sessions cannot be decrypted even if long-term keys are later compromised.
- Certificate validation checks hostname match, expiry, revocation status, and the full signing chain to a trusted root CA. A 'not trusted' error is almost always a chain problem.
- mTLS authenticates both endpoints. Certificate Transparency makes certificate issuance auditable. ECH can hide SNI where deployed. HTTPS confirms transport encryption, not the trustworthiness of the site or its operator.
Standards and sources cited in this module
RFC 8446, The Transport Layer Security (TLS) Protocol Version 1.3
Section 2, Protocol Overview; Section 4.1, Key Exchange Messages
Defines TLS 1.3, the 1-RTT handshake, 0-RTT resumption, and the requirement for forward secrecy. Quoted in Section 14.2.
RFC 9162, Certificate Transparency Version 2.0
Section 1, Introduction; Section 2, Cryptographic Components
Defines the current Certificate Transparency Version 2.0 specification. Referenced in Section 14.3 for the audit-log mechanism and version boundary.
RFC 9849, TLS Encrypted Client Hello
Abstract and protocol overview
Defines ECH, which changes what passive observers can learn from the TLS ClientHello. Referenced in Section 14.1.
OpenSSL Security Advisory: Heartbleed (CVE-2014-0160)
Published April 7, 2014
Original disclosure of the Heartbleed vulnerability. Used in the opening case study to illustrate the boundary between TLS protocol security and implementation security.
CompTIA Network+ N10-009 Exam Objectives
Domain 4.0, Network Security; Objective 4.3: TLS and encryption
TLS handshake, certificate chain validation, and common TLS errors appear in the Network+ security objectives.
TLS protects data in transit. Module 15 puts everything from the Applied stage into a repeatable troubleshooting method: turning symptoms into observables, using timing to narrow the search space, and keeping changes scoped and reversible.
Module 14 of 21 · Applied stage