Encryption in Transit: TLS, IPsec, and Secure Protocols(OBJ.1.3)

Run a packet capture on a busy guest Wi-Fi network, follow one TCP stream on port 21, and you may watch a service account's username and password scroll past in plain text. Nothing was hacked; the protocol simply never encrypted anything. Every cleartext protocol still running on a network hands the same information to anyone who can see the traffic.

On the CompTIA Security+ SY0-801 exam, encryption in transit sits under objective 1.3, which expects you to pick the right cryptographic solution, and the right protocol, for a job. This lesson covers how TLS sets up an encrypted session, how to read a cipher suite, how IPsec and SSH protect traffic, and which secure protocol and port replaces each insecure one.

Encryption in transit protects data crossing networks you don't control

Data in transit passes through switches, Wi-Fi access points, ISP routers and cloud networks that belong to other people. An attacker on any of them can read traffic by sniffing, alter it in an on-path attack, or steal session tokens and reuse them. This is what an unencrypted FTP login looks like in a capture:

220 FTP server ready
USER backupsvc
331 Password required for backupsvc
PASS Winter2026
230 User backupsvc logged in

Secure transport protocols provide three things together: confidentiality, so captured traffic is unreadable; integrity, so altered packets are detected and dropped; and authentication of at least the server, so the client knows it reached the real system and not an impostor. They all use the hybrid design from the asymmetric encryption lesson: an asymmetric exchange sets up symmetric session keys, and a fast cipher such as AES-GCM carries the data.

The protocols differ mainly in where they sit. TLS protects one application connection at a time, such as a single HTTPS session. IPsec works at the network layer and can protect all IP traffic between two hosts or two networks. SSH protects remote administration and file transfer. Wireless encryption such as WPA3 protects only the hop between a device and the access point, so it doesn't replace any of these.

TLS 1.3 sets up an encrypted session in one round trip

TLS (Transport Layer Security) is the protocol behind HTTPS and most other secure application protocols. SSL, its predecessor, and TLS 1.0 and 1.1 are deprecated and should be disabled. TLS 1.2 is the minimum acceptable version and TLS 1.3 is preferred. People still say "SSL certificate" out of habit, but no current system should negotiate SSL.

A TLS 1.3 handshake, at the level the exam expects, works like this:

1. The client sends a ClientHello listing the TLS versions and cipher suites it supports, a random value, and its ephemeral ECDHE public key, called the key share.
2. The server replies with a ServerHello that picks the version and cipher suite and includes its own key share. Both sides can now compute the same shared secret and derive session keys.
3. Already under encryption, the server sends its certificate and a signature over the handshake made with its private key, which proves it owns the certificate. It finishes with a Finished message that confirms nothing in the handshake was altered.
4. The client checks the certificate and the signature, sends its own Finished message, and application data flows encrypted with AES-GCM or ChaCha20-Poly1305.

That's one round trip before the client can send data. TLS 1.2 needed two, negotiated more options, and allowed weak choices: RSA key transport without forward secrecy, CBC mode, RC4, 3DES and SHA-1. TLS 1.3 removed all of them, encrypts more of the handshake (including the server's certificate), and defines only five cipher suites, all of them authenticated encryption. It also offers 0-RTT resumption, which lets a returning client send data immediately, at the cost that this early data can be replayed. How the client decides to trust the certificate is covered in the PKI section, and downgrade attacks that try to force old versions are covered with network attacks.

TLS can also authenticate the client. In mutual TLS (mTLS) both sides present certificates, which is common between services and for device authentication.