Night Class | A TLS journey - part 1
Night Class is a comic series that provides research, to a technical audience, in a fun way.
A TLS journey is a narrative driven exploration of how TLS works using the styling of a 1960’s sci-fi comic book.
This is part 1 of A TLS Journey; in which we explore how TLS 1.3 connections work
There are only so many livable planets for an escape pod to target. Let's hope this one's not hostile to aliens—or interested in eavesdropping on them.
Good thing all my communication is encrypted with TLS 1.3.
When I send a distress beacon to Intergalactic Road-Side Assistance, TLS will keep the communication between my devices and their dispatch servers authenticated and encrypted.
TLS negotiates after the TCP handshake, before any application data flows.
The client sends a ClientHello: cipher suites it supports, its public key (key_share), and the server name it wants to reach (SNI).
The server responds with a ServerHello (chosen cipher suite and its public key), then immediately sends—now encrypted—its certificate chain, a signature proving it possesses the private key, and a Finished message verifying handshake integrity.
Both sides derive the same shared secrets from the exchanged keys.
Finally, the client verifies everything and sends its own Finished message, followed immediately by application data.
Reducing round trips matters. The worse your latency, and the greater your network congestion, the more you gain.
To reduce the TLS handshake to one round-trip, TLS 1.3 allows the client to make educated guesses about which cryptographic parameters the server supports, sending key shares speculatively.
If wrong, the server responds with a HelloRetryRequest, adding one extra round trip. But the gamble usually pays off—clients guess correctly based on common configurations.
TLS 1.3 also encrypts everything after ServerHello—including the server's certificate—preventing passive observers from seeing which servers you're connecting to.
Metadata is protected as packets travel across the universe*.
*Note: SNI still travels in cleartext in standard TLS 1.3; Encrypted Client Hello fixes this.
Once the handshake completes, TLS 1.3 uses forward secrecy. Each session generates ephemeral Diffie-Hellman keys, uses them once, then destroys them. If an attacker steals the server's private key later, past sessions stay encrypted. The keys are gone.
Each direction gets unique encryption keys derived from an application traffic secret. Every record has a sequence number preventing replay attacks. Messages use AEAD ciphers (AES-GCM or ChaCha20-Poly1305) for confidentiality and integrity.
A proper TLS close requires both sides to send a close_notify alert before closing the TCP connection.
When the TLS connection closes (clean or abrupt), a new handshake is required to reconnect. Session resumption makes this faster. After the initial handshake, the server sends a NewSessionTicket containing a pre-shared key (PSK). If the client reconnects within the ticket_lifetime, it presents this ticket and skips certificate verification.
The connection was successful & Intergalactic roadside-assistance is on the way.
Swing down sweet chariot, stop and let me ride.