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?
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.
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).
“TLS 1.3 achieves a 1-RTT handshake and 0-RTT resumption. The key exchange is done in the first round trip, and the server can be authenticated in the same flight.”
RFC 8446 - Section 2, Protocol Overview
The 1-RTT design was a deliberate improvement over TLS 1.2. Each removed round trip is significant on high-latency connections. A single TLS handshake on a 100 ms RTT link costs 100 ms in 1.3, compared to 200 ms in 1.2.
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), defined in RFC 6962, adds an audit log requirement. CAs must submit certificates to public, append-only logs. Browsers can require proof that a certificate appears in at least two CT logs before trusting it. This allows domain owners and security researchers to detect misissued certificates.
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?
Key takeaways
- 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. 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 6962, Certificate Transparency
Section 1, Introduction; Section 3, Log Format
Defines the Certificate Transparency append-only log system. Referenced in Section 14.3 for the audit mechanism description.
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