Why TLS Matters

Transport Layer Security is the most widely deployed cryptographic protocol on Earth. Every HTTPS connection, every email transmission, every API call depends on it.

TLS Evolution

Two decades of protocol refinement, driven by real-world attacks and performance demands.

What TLS 1.3 Removed

The most important design decision in TLS 1.3 was what to delete. Every removed feature had been the source of real-world attacks.

TLS 1.3 Cipher Suites

TLS 1.2 had 37+ cipher suites with complex negotiation. TLS 1.3 has exactly 5, all AEAD-only. Key exchange and authentication are negotiated separately.

The Full Handshake — 1-RTT

TLS 1.3 completes the handshake in a single round trip. The client sends key shares speculatively, enabling encrypted data after just one flight.

ClientHello in Detail

The ClientHello is the only unencrypted message from the client. It must contain enough information for the server to complete key exchange in a single round trip.

ClientHello {
    legacy_version:           0x0303        // TLS 1.2 for middlebox compat
    random:                   32 bytes      // Client random nonce
    legacy_session_id:        32 bytes      // Compatibility mode
    cipher_suites:            [0x1301, 0x1302, 0x1303]
    legacy_compression:       [0x00]        // Null only
    extensions: {
        supported_versions:   [0x0304]      // TLS 1.3
        key_share:            X25519 pubkey (32 bytes)
                              P-256 pubkey  (65 bytes)
        signature_algorithms: [ed25519, ecdsa_secp256r1_sha256,
                               rsa_pss_rsae_sha256, ...]
        server_name (SNI):    "example.com"
        psk_key_exchange_modes: [psk_dhe_ke]
    }
}

ServerHello + EncryptedExtensions

The server selects one cipher suite, one key share group, and sends its ephemeral public key. Everything after ServerHello is encrypted.

ServerHello {
  legacy_version: 0x0303
  random:         32 bytes
  cipher_suite:   0x1301
                  (AES_128_GCM_SHA256)
  extensions: {
    supported_versions: 0x0304
    key_share: X25519 pubkey
  }
}

{EncryptedExtensions} {
  server_name:          ack
  max_fragment_length:  ...
  alpn:                 "h2"
  // No key-exchange or
  // auth-related extensions
  // (those stay in ServerHello)
}

ECDHE Key Exchange

The core of TLS 1.3 security — ephemeral Elliptic Curve Diffie-Hellman. Connects directly to Module 02 (ECC).

Key Schedule — HKDF Derivation

TLS 1.3 derives all keys through a structured HKDF pipeline. Two primitives from Module 05 (Hashing): HKDF-Extract (combine entropy) and HKDF-Expand (derive keys).

Server Authentication

After key exchange, the server proves its identity with three encrypted messages. All sent under handshake traffic keys.

Client Finished — Handshake Complete

The client verifies the server's Certificate, CertificateVerify, and Finished. Then it sends its own Finished message to complete the handshake.

0-RTT Resumption

Returning clients can send encrypted application data in the very first flight — zero round trips before data. But this comes with significant security trade-offs.

Pre-Shared Key Modes

TLS 1.3 supports two PSK modes for resumption and external PSK use cases.

Session Tickets

After the handshake completes, the server sends NewSessionTicket messages enabling future resumption without server-side state.

NewSessionTicket {
    ticket_lifetime:    7200                // Max 604800s (7 days)
    ticket_age_add:     0x4a2bc8e1          // Obfuscate ticket age
    ticket_nonce:       0x0000000000000001  // Unique per ticket
    ticket:             <encrypted blob>    // Server-encrypted state
    extensions: {
        early_data:     max_early_data_size: 16384
    }
}

Certificate Handling

TLS 1.3 carries X.509 certificate chains with inline extensions for revocation checking and certificate transparency.

Signature Schemes

TLS 1.3 defines specific signature algorithms for CertificateVerify. Connecting to Module 06 (Digital Signatures).

Record Protocol — AEAD Encryption

All application data (and handshake messages after ServerHello) is encrypted using the AEAD cipher from the negotiated suite. Connects to Module 03 (AES-GCM) and Module 04 (ChaCha20-Poly1305).

TLSCiphertext {
    opaque_type:     0x17 (application_data)  // Always 0x17!
    legacy_version:  0x0303                    // Always TLS 1.2
    length:          uint16                    // Encrypted payload length
    encrypted_record:
        AEAD-Encrypt(
            key:   write_key,
            nonce: write_iv XOR sequence_number,
            aad:   TLSCiphertext header (5 bytes),
            plaintext: content || ContentType || zeros
        )
}

Middlebox Compatibility Mode

The most pragmatic hack in TLS 1.3: it disguises itself as TLS 1.2 on the wire to avoid being broken by enterprise middleboxes.

Security Analysis

TLS 1.3 is the most formally analyzed cryptographic protocol in history. Multiple independent verification efforts proved its security properties.

TLS 1.3 vs TLS 1.2

A side-by-side comparison of the two protocol generations.

Post-Quantum TLS

Quantum computers threaten ECDHE key exchange. The transition to post-quantum TLS is already underway. Connecting to Module 07 (Post-Quantum Cryptography).

On the Wire — What Wireshark Sees

A TLS 1.3 handshake as captured in a packet trace. Note how everything after ServerHello appears as opaque Application Data.

Frame 1: ClientHello (227 bytes)
  16 03 01 00 e0        # Record: Handshake, TLS 1.0 (compat!)
  01 00 00 dc           # ClientHello, length 220
  03 03                 # legacy_version: TLS 1.2
  [32 bytes random]
  20 [32 bytes session_id]     # Compatibility mode
  00 06 13 01 13 02 13 03      # 3 cipher suites
  01 00                        # Compression: null
  00 91                        # Extensions length
    00 2b 00 03 02 03 04       # supported_versions: TLS 1.3
    00 33 00 47 00 45          # key_share: X25519
      00 1d 00 20 [32 bytes pubkey]
    00 0d 00 14 ...            # signature_algorithms
    00 00 00 0f ...            # server_name: example.com

Frame 2: ServerHello (155 bytes)
  16 03 03 00 97        # Record: Handshake, TLS 1.2 (compat!)
  02 00 00 93           # ServerHello
  03 03 [32 bytes random]
  20 [32 bytes session_id]     # Echo client's session_id
  13 01                        # Selected: TLS_AES_128_GCM_SHA256
    00 2b 00 02 03 04          # supported_versions: TLS 1.3
    00 33 00 24 00 1d 00 20    # key_share: X25519
      [32 bytes server pubkey]

Frame 3: Change Cipher Spec (6 bytes)  # Fake! Compatibility mode
  14 03 03 00 01 01

Frame 4-7: Application Data (opaque)   # All encrypted from here
  17 03 03 [len] [encrypted EncryptedExtensions]
  17 03 03 [len] [encrypted Certificate]
  17 03 03 [len] [encrypted CertificateVerify]
  17 03 03 [len] [encrypted Finished]

TLS 1.3 Implementations

Major implementations with different design philosophies and security profiles.

HKDF Internals

HKDF (HMAC-based Key Derivation Function, RFC 5869) is the engine behind TLS 1.3's key schedule. Two operations, each a single HMAC call.

PRK = HMAC-Hash(salt, IKM)
// Extracts entropy from input
// keying material (IKM) into a
// fixed-length pseudorandom key
// salt = previous Derive-Secret
// IKM = PSK or ECDHE secret

HKDF-Expand-Label(Secret, Label,
                   Context, Length)
= HKDF-Expand(Secret,
    HkdfLabel, Length)

HkdfLabel = Length ||
  "tls13 " || Label ||
  Hash(Context)

Derive-Secret(Secret, Label, Messages)
    = HKDF-Expand-Label(Secret, Label, Transcript-Hash(Messages), Hash.length)

// Example: deriving handshake traffic secret
client_handshake_traffic_secret =
    Derive-Secret(Handshake Secret, "c hs traffic", ClientHello...ServerHello)

Finished Message & Key Update

finished_key = HKDF-Expand-Label(
    base_key,           // {client,server}_handshake_traffic_secret
    "finished", "", Hash.length
)

verify_data = HMAC(finished_key, Transcript-Hash(
    Handshake Context ... last message before Finished
))

application_traffic_secret_N+1 =
    HKDF-Expand-Label(application_traffic_secret_N,
                       "traffic upd", "", Hash.length)

// New write key and IV derived from new secret
// Triggered via KeyUpdate message (encrypted)
// Provides key rotation without new handshake

References & Standards