Week 10: TLS -- Encryption and the CVE Quartet

TLS (Transport Layer Security) is the layer that encrypts HTTPS, SMTPS, IMAPS, and most other secure Internet protocols. This week you trace the TLS handshake in a packet capture and work through the academy's Wireshark CVE quartet: four real vulnerabilities that show what happens when a parser trusts wire-format length fields without bounds-checking.

Theme

When you open https://virtuscyberacademy.org, the TLS handshake completes before any HTTP data flows. During the handshake, the client and server agree on a cipher suite, exchange certificates, and establish a shared symmetric key. After the handshake, all application data is encrypted. A passive observer on the network can see the handshake (it is mostly in the clear), can see the SNI (the hostname the client is connecting to), and can see the size and timing of encrypted records -- but cannot read the content. This week you see what is visible and what is not.

The Wireshark CVE quartet, covered in lab 10-2, shows what happens when a TLS dissector processes a malformed ClientHello. Four CVEs, four bug shapes, all related to the same principle: trusting the length fields in a wire-format packet without verifying that those lengths actually fit in the buffer.

Reading (~60 minutes)

1. Kurose & Ross Ch 8 §8.6 ("Securing TCP Connections: TLS"): the TLS handshake at a conceptual level; certificates; symmetric key establishment
2. The academy handout: handouts/cve-lab-wireshark-rce-quartet-2026-05.md -- §0.5 (Lab scope) + §1 (CVE-2026-5402, TLS dissector RCE) only for this week's lecture; the other three CVEs are covered in Lab 10-2
3. Optional: RFC 8446 §2 (TLS 1.3 overview): a short plain-English summary of the TLS 1.3 handshake flow

Lecture outline (~2 hours)

Section 1: What TLS provides and does not provide

TLS provides:

• Confidentiality: data is encrypted with a symmetric key known only to the two parties
• Integrity: AEAD (Authenticated Encryption with Associated Data) detects any tampering with the ciphertext
• Authentication: the server presents a certificate signed by a trusted Certificate Authority; the client verifies the signature chain

TLS does NOT provide:

• Anonymity: TLS does not hide who you are connecting to. The IP address of the server is visible in the IP header. The SNI (Server Name Indication) field in the ClientHello contains the hostname you are connecting to, in plaintext. A network observer can see virtuscyberacademy.org in the SNI even if they cannot read the HTTPS response body.
• Forward secrecy (optional but common): with ECDHE key exchange, the session key is generated fresh for each connection and not derived from the server's certificate private key. If the server's private key is later compromised, past sessions remain confidential. Without forward secrecy, compromising the private key decrypts all past recorded sessions.

Section 2: The TLS 1.3 handshake

TLS 1.3 simplified the handshake compared to TLS 1.2:

1. ClientHello (client -> server): TLS version, random nonce, list of supported cipher suites, key_share extension (the client's Diffie-Hellman public key), SNI extension, and other extensions
2. ServerHello (server -> client): chosen cipher suite, the server's key_share, session ID
3. {Certificate, CertificateVerify, Finished} (server -> client, all encrypted): the server's certificate chain, a signature proving it holds the private key, and the Finished MAC that closes the handshake
4. {Finished} (client -> server, encrypted): the client's Finished MAC
5. {Application data} (both directions, encrypted): HTTP request/response data

In TLS 1.3, the application data begins after only one round trip (1-RTT). TLS 1.2 required two round trips.

Browser tool: TLS 1.3 handshake replay. Open the academy-tls13.pcap capture in pcap-tools and watch the six packets walk the state machine from START to CONNECTED on both endpoints. The replay-mode panel sits above the standard packet table; each Step click advances both endpoints' state pills and surfaces an authored callout explaining what changed. Companion lab spec at labs/lab-tls-13-handshake-replay.md.

Figure 10.1. TLS 1.3 in one round trip. The diagram makes the encrypted-vs-plaintext boundary explicit (the shaded region begins right after ServerHello), which is the conceptual point of Section 3: everything an on-path observer can read is above the boundary, everything they cannot read is below. The SNI in step 1 stays visible until Encrypted Client Hello (ECH) lands; the Certificate in step 3 is now encrypted (TLS 1.2 sent it in the clear).

Section 3: What you can see in a capture

In tls-handshake.pcapng (from the academy pcap catalog, fixtures/net-201/upstream-mirror/):

• ClientHello: visible in plaintext. Wireshark displays: handshake type (1 = ClientHello), supported TLS versions, cipher suites list, all extensions. The SNI extension contains the target hostname.
• ServerHello: visible in plaintext. Handshake type (2), chosen cipher suite, key_share.
• After the Finished messages: all subsequent records are marked "Application Data" in Wireshark. You can see the encrypted record sizes and timing but not the content.

Display filter: tls.handshake.type == 1 for ClientHello; tls.handshake.type == 2 for ServerHello; tls.record.content_type == 23 for application data records.

Section 4: Certificates and the trust chain

• A TLS certificate contains the server's public key, the hostname(s) it is valid for, a validity period, and a digital signature from a Certificate Authority (CA)
• The client has a pre-installed list of trusted root CAs (maintained by the OS or browser)
• The server sends a chain: server certificate, signed by an intermediate CA, signed by a root CA
• The client verifies: (a) the hostname in the certificate matches what it connected to, (b) the chain is valid and unmodified, (c) the leaf certificate has not expired, (d) the leaf certificate has not been revoked

Section 5: The CVE quartet connection to TLS dissectors

The Wireshark TLS dissector (CVE-2026-5402) processes the ClientHello's extensions. It parses length fields from the wire format and uses them to compute offsets and buffer sizes. A crafted ClientHello can carry extension length values that, when processed with 16-bit integer arithmetic, truncate or underflow. The dissector then writes past the end of its heap-allocated buffer.

The principle: never trust a length field from an untrusted source without bounds-checking it against the actual buffer size. This is the same principle FND-101 taught for file format headers. At the network layer, the wire-format bytes have the same threat model as a malformed file: an attacker controls them.

The academy mini-module at /vca-mini-wireshark-cves-2026-05/ has the full CVE vocabulary; you are reading one of the four CVEs in depth this week and will cover all four in Lab 10-2.

Labs (~90 minutes)

Lab 10-1: TLS Handshake (labs/lab-10-1-tls-handshake.md) Lab 10-2: Wireshark CVE Mini-Module (labs/lab-10-2-wireshark-cves-mini.md)

Independent practice (~7 hours)

1. Read Kurose & Ross Ch 8 §8.6 in full
2. Load tls-handshake.pcapng in pcap-tools. Expand the ClientHello in Wireshark. Write down: the supported TLS versions; the first three cipher suites listed; the SNI value; which extensions are present
3. Apply tls.handshake.type == 1 to the TLS capture. How many ClientHellos are there? When would a capture contain more than one?
4. Read §1 of handouts/cve-lab-wireshark-rce-quartet-2026-05.md (CVE-2026-5402) fully. In your own words, describe the bug at a vocabulary level: where in the code does it live, what data type is used, and what input condition triggers the overflow.
5. Visit /vca-mini-wireshark-cves-2026-05/ on the academy site. For each of the four CVEs, write one sentence describing the bug class and one sentence describing the defensive lesson.

Reflection prompts (~30 minutes)

1. TLS encrypts the HTTP body but not the SNI in the ClientHello. An observer watching your HTTPS traffic can still see every hostname you connect to. What does "Encrypted Client Hello" (ECH, referenced in CVE-2026-5402) try to do about this?
2. Certificate Authorities are trusted by default by your OS or browser. What happens when a CA is compromised and issues fraudulent certificates? (Look up DigiNotar, 2011.)
3. TLS 1.2 is still widely deployed. TLS 1.2 supports cipher suites considered weak by modern standards (e.g., RC4, export-grade key sizes). How do organizations manage the transition to TLS 1.3?
4. CVE-2026-5402 is a vulnerability in a tool designed to help security analysts (Wireshark). What does this say about the threat model of security tools themselves?
5. "The capture file contains a malformed packet that could trigger a vulnerability in unpatched Wireshark." The academy's pcap-tools workbench loads these captures safely because it runs tshark in a sandboxed environment. What design principle does this implement?

What comes next

Week 11 covers Network Security Monitoring: display filters, analytical techniques, and how to use the pcap-tools workbench in a structured investigation. You will also map the academy's Snort 3 and Suricata rules to the CVEs they detect.