Old-School Networking

• Layers 5 and 6 — presentation (character encoding, JSON, compression, encryption) and session
• Switching to HTTPS — what disappears and how much slower it is (measured)
• Keys and certificates — sharing a key, certificate chains, four ways verification fails (measured)
• Still visible — the name (SNI) and ECH, which hides it; certificate lifetimes getting shorter

Layer 6 is presentation. The same word is unreadable unless both sides lay it out by the same rules. Today's rules: UTF-8 for text, JSON for data, gzip for compression.

# 交通費 (“travel”) is 9 bytes in UTF-8 (also visible in the bytes pane of part 7's cover)
    交通費 → e4 ba a4 e9 80 9a e8 b2 bb
# gzip on the 2 MB CSV (the same line repeated, so it shrinks absurdly)
    2,097,152 bytes → 6,179 bytes

Layer 5 is session: starting and ending a conversation and resuming it after a break. In practice it's spread across TCP connections, HTTP cookies, TLS session resumption and so on. Encryption is a form of presentation too, so TLS does work that spans both layers.

At the end of part 7 we noticed the submission's JSON was readable in Wireshark. Let's search the capture files for the submission's text.

# Searching the capture files for the submission's text
    HTTP   '"amount":1280'       found
    HTTP   'POST /api/expenses'  found
    HTTPS  '"amount":1280'       not found
    HTTPS  'POST /api/expenses'  not found
    HTTPS  'expenses.example'    found  ← Client Hello SNI

The HTTP capture contains the URL and the amount as is. Past every router along the way, anyone on the same Wi-Fi, every machine at the provider, it travelled readable. And what can be read can be altered and passed on. In the HTTPS capture, neither the URL nor the amount could be found, with one exception: the name expenses.example (section 7).

We gave the server a certificate for the name expenses.example and ran the expenses API over Node.js https on port 3443 (.example is a name reserved for documentation). The certificate was issued by a practice CA the author created, “Kiji Practice Root CA”, and the PC's curl was told about that CA with --cacert.

With a 0.041 s round trip, HTTP took 2 round trips to the reply. HTTPS with TLS 1.3 added one round trip for the TLS greeting, making 3, and the older TLS 1.2 added two, making 4. The cryptography itself took only a few milliseconds. The slowness is round trips, not computation.

# TLS 1.3 (20 ms each way): after TCP's greeting, TLS's takes one round trip; the request (no. 9) is encrypted
   1  0.000  pc  → srv  TCP      [SYN]
   2  0.041  srv → pc   TCP      [SYN, ACK]
   3  0.041  pc  → srv  TCP      [ACK]
   4  0.043  pc  → srv  TLSv1    Client Hello (SNI=expenses.example)
   5  0.083  srv → pc   TCP      [ACK]
   6  0.084  srv → pc   TLSv1.3  Server Hello, Change Cipher Spec, Application Data, Application Data, Application Data, Application Data
   7  0.084  pc  → srv  TCP      [ACK]
   8  0.085  pc  → srv  TLSv1.3  Change Cipher Spec, Application Data
   9  0.086  pc  → srv  TLSv1.3  Application Data
  10  0.126  srv → pc   TLSv1.3  Application Data, Application Data
  11  0.130  srv → pc   TLSv1.3  Application Data
# TLS 1.2: two round trips of TLS greeting before the request (no. 10)
   1  0.000  pc  → srv  TCP      [SYN]
   2  0.041  srv → pc   TCP      [SYN, ACK]
   3  0.041  pc  → srv  TCP      [ACK]
   4  0.042  pc  → srv  TLSv1    Client Hello (SNI=expenses.example)
   5  0.083  srv → pc   TCP      [ACK]
   6  0.083  srv → pc   TLSv1.2  Server Hello, Certificate, Server Key Exchange, Server Hello Done
   7  0.083  pc  → srv  TCP      [ACK]
   8  0.085  pc  → srv  TLSv1.2  Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message
   9  0.128  srv → pc   TLSv1.2  Change Cipher Spec, Encrypted Handshake Message
  10  0.128  pc  → srv  TLSv1.2  Application Data
  11  0.170  srv → pc   TLSv1.2  Application Data

In TLS 1.3 the PC sends its key material up front in the first Client Hello, so encryption is ready as soon as the server's reply (Server Hello) arrives. Everything after Server Hello, the certificate included, is already encrypted. TLS 1.2 needed another round trip to exchange that material. TLS 1.0 and 1.1 were formally deprecated in 2021.

The PC and the server each make a secret number and exchange only a “public” number computed from it, in the Client Hello and Server Hello. Combining your own secret with the other side's public number gives both sides the same key. Seeing the public numbers along the way isn't enough to compute it. The secrets are made fresh for each connection and thrown away, so even if the server's long-term key leaks later, old recordings can't be unlocked (forward secrecy).

# openssl s_client shows what was agreed
pc$ openssl s_client -connect 203.0.113.20:3443 -servername expenses.example -CAfile ca.pem -brief
    Protocol version: TLSv1.3
    Ciphersuite: TLS_AES_256_GCM_SHA384
    Peer certificate: CN = expenses.example
    Hash used: SHA256
    Signature type: ECDSA
    Verification: OK
    Server Temp Key: X25519, 253 bits
# The chain (0 is the server; i: is who signed it)
    0 s:CN = expenses.example
    i:CN = Kiji Practice Root CA
    Verify return code: 0 (ok)
# The server's certificate
    subject=CN = expenses.example
    issuer=CN = Kiji Practice Root CA
    notBefore=Oct 24 23:40:01 2026 GMT
    notAfter=Jan 22 23:40:01 2027 GMT
    DNS:expenses.example

openssl s_client shows this connection used TLS 1.3, X25519 to share the key and TLS_AES_256_GCM_SHA384 for the contents. AES-256-GCM encrypts and adds a “not tampered with” check at the same time, covering two of the three promises. The third, whether the other side is genuine, is the certificate's job.

However safely you share a key, if the server is a fake you're just talking safely to a fake. So the server shows a certificate saying “I am expenses.example”. It holds a name, validity dates and a public key, and is signed by a trusted CA.

A real site's certificate is signed via an intermediate CA by a “root CA” that the OS or browser trusts out of the box. The PC checks three things: the name matches, it's within its dates, and the signatures lead to a root. This part's practice CA isn't in the PC's list, so we told curl to trust it.

Here are the errors every developer meets sooner or later, caused on purpose. The wrong-name, expired and self-signed certificates were all made for the exercise.

# Connect without telling curl about the practice CA
    curl: (60) SSL certificate problem: unable to get local issuer certificate
# Connect by address (IP); the certificate's name is expenses.example
    curl: (60) SSL: no alternative certificate subject name matches target host name '203.0.113.20'
# An expired certificate (valid until 2026-09-29)
    curl: (60) SSL certificate problem: certificate has expired
# A certificate signed by itself
    curl: (60) SSL certificate problem: self-signed certificate
# Practice CA given, connecting by name → verification succeeds
    HTTP 404 (GET /api/expenses)

As the cover photo shows, the Client Hello's SNI carries the name of the server being contacted, expenses.example, in the clear. When one server hosts sites under many names, it has to know which certificate to present before encryption starts. Beyond that, the server's IP address, how much is sent and when are all visible along the way even with TLS.

To hide the name, ECH (Encrypted Client Hello), which encrypts the Client Hello itself, became a standard as RFC 9849 in March 2026. The name also leaks through DNS lookups (part 9), though, so both need covering before it's truly hidden.

The CA/Browser Forum, the industry body of browsers and CAs, has decided to shorten public certificate lifetimes in stages: at most 200 days from 15 March 2026, and 47 days from 15 March 2029. Renewing by hand several times a year isn't realistic, so issuing and renewing automatically with the ACME protocol becomes the norm. Let's Encrypt, the free CA, hands out its certificates over ACME.

For developers, the job is to prevent “the site went down because the certificate expired” with monitoring and automatic renewal. You can check the dates with openssl x509 -noout -dates or through the browser's padlock.

Click the icon to the left of the browser's address bar to see a site's certificate. Have a look at the issuing CA, the name and the dates.