Transport Layer Security (TLS) — SY0-701

WHAT IT IS

Transport Layer Security (TLS) is a cryptographic protocol that provides privacy and data integrity between two communicating applications. According to NIST SP 800-95, it "is designed to encapsulate other protocols, such as HTTP." RFC 8446 (TLS 1.3) states the protocol is designed to "prevent eavesdropping, tampering, and message forgery."

TLS is composed of two layers (CNSSI 4009-2015):

• TLS Record Protocol — uses negotiated cryptographic parameters to protect traffic as independently secured records.
• TLS Handshake Protocol — authenticates the parties, negotiates a cipher suite, and establishes shared keying material before any application data flows.

Mental model

Think of TLS as a secure tunnel dug between two specific applications before they speak. The handshake digs the tunnel and verifies who is on the other end; the record layer is the tunnel itself, carrying every byte that follows. The tunnel is torn down when the session ends — it does not protect the network path for other applications running at the same time.

RFC 8446 names three security properties TLS delivers once the tunnel is open:

1. Authentication — "The server side of the channel is always authenticated; the client side is optionally authenticated."
2. Confidentiality — "Data sent over the channel after establishment is only visible to the endpoints."
3. Integrity — "Data sent over the channel after establishment cannot be modified by attackers without detection."

When to use it

The exam frequently asks candidates to choose between TLS and IPsec. The decision turns on what layer protection is needed and what scope of traffic must be covered.

Property	TLS (RFC 8446)	IPsec (RFC 4301)
Layer of operation	Protects a specific application connection (transport/application layer)	Protects traffic at the IP layer
Traffic scope	One application session at a time	All protocols carried over IP, regardless of application
Who negotiates it	The two communicating applications	Network devices (hosts, gateways)
Typical use case	HTTPS, email submission, database connections	Site-to-site VPNs, host-to-host network encryption
Authentication target	Server always; client optionally (RFC 8446)	Hosts and gateways (RFC 4301)

Use TLS when you need to secure a specific application protocol (wrapping HTTP into HTTPS, for example). Use IPsec when you need to secure all traffic between two network endpoints regardless of which application generates it.

COMMON MISCONCEPTION

"TLS authenticates both sides equally."

RFC 8446 is explicit: server-side authentication is always required, but client authentication is optional. In the vast majority of real deployments (public HTTPS sites), only the server presents a certificate. Candidates who assume mutual authentication is the default will misread scenarios where the question turns on whether the client is verified.

A second trap: "TLS 1.3 supports 0-RTT data with the same security guarantees as normal TLS." RFC 8446 warns directly that 0-RTT data "is not forward secret, as it is encrypted solely under keys derived using the offered PSK" and carries "no guarantees of non-replay between connections." Treating 0-RTT as equivalent to a fully established TLS session is incorrect.

A third misconception conflates TLS with IPsec for VPN scenarios. Because IPsec "provides security services for traffic at the IP layer" (RFC 4301), it secures all traffic between two points at the network layer — TLS secures only the application sessions that explicitly invoke it.

How it shows up on the exam

The cognitive target for TLS questions in Domain 3 (Security Architecture) is selecting the right protocol for a described architecture scenario and distinguishing what each protocol does and does not guarantee.

Candidates are commonly asked to:

• Identify which protocol secures traffic at the network layer versus an application session.
• Determine whether a described deployment provides mutual authentication or server-only authentication.
• Recognize that forward secrecy — the property that compromise of long-term keys does not expose past session traffic — is built into TLS 1.3 by design, because RFC 8446 states "all public-key based key exchange mechanisms now provide forward secrecy" (static RSA and static Diffie-Hellman were removed).
• Distinguish the handshake phase (parameter negotiation and authentication) from the record phase (data protection after establishment).

Signal phrases that point toward a TLS answer: "application layer encryption," "certificate-based server authentication," "HTTPS," "securing a specific protocol," "in transit between client and server."

Signal phrases that point away from TLS toward IPsec: "network layer," "all traffic between two sites," "protocol-agnostic protection," "security gateway."

How TLS 1.3 handshake phases connect

Key exchange occurs first; authentication of the server (and optionally the client) follows inside an already-encrypted channel. This is one of the structural changes from earlier TLS versions documented in RFC 8446.

Related concepts

• Failure Modes — understanding how a TLS misconfiguration (expired certificate, weak cipher suite, disabled verification) leads to security failures.
• Jump Server — jump servers often terminate TLS sessions from administrators; knowing which layer TLS operates at clarifies what a jump server does and does not inspect.
• Intrusion Detection / Prevention — TLS encryption can limit IDS/IPS visibility into application-layer content, making the interaction between these controls an exam-relevant architecture consideration.