TLS Internals

TLS 1.3 implementations should prefer psk_dhe_ke for session resumption. This provides forward Secrecy even for resumed sessions. If the PSK is compromised, past traffic remains secure because The (EC)DHE exchange was ephemeral.

AEAD (Authenticated Encryption with Associated Data) provides both confidentiality and integrity in A single operation. TLS 1.3 requires AEAD ciphers exclusively.

AES-GCM (Galois/Counter Mode):

• AES-128-GCM: 128-bit key, 96-bit nonce, 128-bit authentication tag
• AES-256-GCM: 256-bit key, 96-bit nonce, 128-bit authentication tag
• Hardware-accelerated on most modern CPUs (AES-NI instruction set)
• The most widely deployed AEAD cipher

ChaCha20-Poly1305:

• 256-bit key, 96-bit nonce, 128-bit authentication tag
• Software-optimized design (no special hardware needed)
• Preferred on mobile devices and ARM platforms without AES-NI
• Designed by Daniel J. Bernstein

AES-CCM:

• AES-128-CCM: 128-bit key, CBC-MAC mode
• AES-128-CCM-8: Same but with truncated 64-bit tag (faster but weaker)
• Required for compatibility with constrained IoT devices (RFC 8446 mandates support for at least one CCM cipher)
• Slower than GCM

TLS 1.3 uses HKDF (HMAC-based Extract-and-Expand Key Derivation Function, RFC 5869) for all key Derivation. The key schedule is:

                    0-RTT
                      |
Early Secret = HKDF-Extract(PSK or 0)
                      |
Handshake Secret = HKDF-Extract(DHE shared secret, Early Secret)
                      |
Master Secret = HKDF-Extract(DHE shared secret, Handshake Secret)
                      |
Application Traffic Secret 0
Application Traffic Secret 1  (after KeyUpdate)
...

Each secret is expanded into multiple keys:

Traffic Keys = {
    client_write_key,
    server_write_key,
    client_write_iv,
    server_write_iv
}

The per-record nonce is derived from the IV and a sequence number:

nonce = IV XOR (sequence_number << 64)

The sequence number is a 64-bit counter that increments for each record. Since the sequence number Is included in the nonce, every record has a unique nonce, even with the same IV.

When the server presents a certificate chain, the client builds a verification path:

1. Parse the leaf certificate and extract the issuer’s distinguished name
2. Find the issuer in the chain (or in the client’s trust store)
3. Repeat until a trusted root certificate is reached
4. Verify signatures at each step (each certificate is signed by its issuer)

For each certificate in the chain:

1. Verify the signature algorithm is acceptable (not MD5, not SHA-1)
2. Verify the certificate is within its validity period (not_before to not_after)
3. Verify the certificate has not been revoked (OCSP or CRL)
4. Verify the certificate’s intended purpose (serverAuth for TLS)
5. Verify the certificate’s constraints (name constraints, path length)

OCSP (Online Certificate Status Protocol, RFC 6960):

The client sends a query to the CA’s OCSP responder asking whether a specific certificate is Revoked. The responder returns “good”, “revoked”, or “unknown”.

# Check certificate revocation with openssl
openssl ocsp -issuer intermediate.pem -cert server.pem \
  -url http://ocsp.example.com/ -resp_text

OCSP Stapling (RFC 6066):

The server periodically obtains an OCSP response from the CA and “staples” it to the TLS handshake. The client does not need to contact the CA directly, improving performance and privacy.

# Test OCSP stapling with openssl
openssl s_client -connect example.com:443 -status -servername example.com

CRL (Certificate Revocation List):

The CA publishes a list of revoked certificate serial numbers. The client downloads and checks the List. CRLs can be large and are not updated frequently, making them less practical for real-time Revocation checking.

A DNS record that specifies which CAs are authorized to issue certificates for a domain:

example.com.  IN  CAA  0 issue "letsencrypt.org"
example.com.  IN  CAA  0 issuewild "*.example.com" "letsencrypt.org"

TLS records have a maximum size (configurable, default 16KB). Application data larger than this is Fragmented into multiple records. The receiver reassembles the fragments.

In TLS 1.3, the maximum record size is negotiated via the max_fragment_length extension:

Smaller records reduce latency (the receiver can process data sooner) but increase overhead (more Records = more TLS record headers and MACs).

TLS 1.2 with CBC cipher suites uses MAC-then-Encrypt (MAC the plaintext, then encrypt both). This is Vulnerable to padding oracle attacks (Lucky13, POODLE).

TLS 1.3 uses AEAD ciphers exclusively, which combine encryption and authentication in a single Operation (effectively encrypt-then-MAC). This eliminates padding oracle attacks entirely.

The client sends the server hostname in the ClientHello’s server_name extension. This allows a Single IP address to host multiple TLS-enabled websites (virtual hosting).

# Test SNI
openssl s_client -connect 93.184.216.1:443 -servername example.com

Negotiates the application protocol (HTTP/1.1, HTTP/2, h2c, etc.) during the TLS handshake:

# Test ALPN
openssl s_client -connect example.com:443 -alpn h2,http/1.1

The server encrypts the session state into a ticket and sends it to the client. On a subsequent Connection, the client presents the ticket, and the server decrypts it to resume the session without Storing state.

In TLS 1.3, session tickets are sent via the NewSessionTicket post-handshake message.

The client lists supported TLS versions in this extension. The server responds with the selected Version in the ServerHello. This extension allows TLS 1.3 to be negotiated without changing the Legacy_version field.

Contains the PSK identity and the binder value (an HMAC over the transcript up to this point, using The PSK). The binder prevents a man-in-the-middle from substituting a different PSK.

Forward secrecy (also called perfect forward secrecy, PFS) ensures that compromising the server’s Private key does not compromise past session keys. Each session uses an ephemeral key exchange, so Recording encrypted traffic and later obtaining the server’s private key does not allow decryption Of past sessions.

Without forward secrecy (static RSA key exchange), the session key is encrypted with the server’s Static RSA private key. If an attacker records the handshake and later obtains the private key (through theft, court order, or cryptanalysis), they can decrypt all past sessions.