Day 6: RFC 8446 §1–3 and the Record Layer

Phase 1 · May 19, 2026

Agenda (2–3 hours)

• Read (75 min): RFC 8446 §1 Introduction, §2 Operational Overview, §5 Record Protocol — read carefully, annotate
• Study (45 min): Record layer structure, ContentType, TLSPlaintext vs TLSCiphertext
• Practice (30 min): Wireshark capture
• Challenge (30 min): Sequence diagram

TLS Protocol Layers

+------------------+  ← Application layer (HTTP, etc.)
|  Handshake       |  ← negotiates keys and authenticates
|  Alert           |  ← error/close signaling
|  Change Cipher   |  ← legacy, kept for middlebox compat (always 1 byte 0x01)
+------------------+
|  Record Layer    |  ← fragments and encrypts/decrypts everything below
+------------------+
|  TCP             |

The Record Layer is TLS's transport. Everything is wrapped in TLS records.

TLSPlaintext Record (pre-encryption)

struct {
    ContentType type;        // 1 byte: handshake(22), alert(21), appdata(23)
    ProtocolVersion version; // 2 bytes: always 0x0303 (TLS 1.2) for compat
    uint16 length;           // 2 bytes: length of fragment
    opaque fragment[length]; // the payload
} TLSPlaintext;

Note: the version field in the record header is always 0x0303 in TLS 1.3
for backward compatibility with middleboxes. Actual version is negotiated via
supported_versions extension.

TLSCiphertext Record (post-encryption)

struct {
    ContentType opaque_type = application_data; // always 23, hides real type
    ProtocolVersion legacy_record_version = 0x0303;
    uint16 length;
    opaque encrypted_record[length]; // AEAD ciphertext + tag
} TLSCiphertext;

The real ContentType is encrypted inside the record (as the last byte before padding).
This hides whether traffic is handshake data or application data from observers.

RFC 8446 §2: Operational Overview

The §2 overview figure is one of the most important pages in the RFC.
Key phases:

1. ClientHello / ServerHello — negotiate parameters, exchange key shares
2. Encrypted Extensions, Certificate, CertificateVerify, Finished — sent encrypted with handshake keys
3. Application Data — sent encrypted with application traffic keys

Total round trips: 1-RTT for a fresh handshake, 0-RTT possible on resumption.

Practice Exercise

# Install Wireshark if not present, or use tshark
# Capture a TLS connection
tshark -i any -f "port 443" -w /tmp/tls_cap.pcapng &
curl -s https://example.com > /dev/null
kill %1

# Inspect record types (content type 22=handshake, 23=appdata, 21=alert)
tshark -r /tmp/tls_cap.pcapng -Y "tls" -T fields \
  -e frame.number -e tls.record.content_type -e tls.record.length

Challenge Assignment

Draw a sequence diagram of a complete TLS 1.3 full handshake from memory,
then verify it against RFC 8446 §2 Figure 1.

Your diagram must show:

1. All messages in order with arrows (Client Server)
2. Which messages are encrypted (and with which key: hs_traffic or app_traffic)
3. Where the key schedule produces new traffic secrets
4. The position of Application Data relative to the Finished message

Use ASCII art, draw.io, or paper+photo — whatever you'll actually do.

Resources

• RFC 8446 §1, §2, §5: rfc-editor.org/rfc/rfc8446
• The §2 figure is at approximately page 12 of the RFC PDF
• Cloudflare blog: "A Detailed Look at RFC 8446 (a.k.a. TLS 1.3)"