3.3 How Websites and Email Use Internet Protocols
Encapsulation is the whole story
Every request you make is the same trick repeated: a protocol adds a header, hands the result down, and the next layer wraps that in its own header. Type a URL with scheme https and the browser produces an HTTP/2 request, TLS encrypts it into records, TCP slices records into segments, IP addresses those segments as packets, and the Ethernet driver frames packets with a 14-byte header and a 4-byte FCS trailer. On a 1500-byte Ethernet MTU, subtracting 20 bytes of IP and 20 of TCP leaves an MSS around 1460; over Wi-Fi with SNAP headers it is often 1400. Each layer can be attacked or hardened separately, which is why "HTTPS is on" says nothing about routing and "filtered" says nothing about certificate validation.
HTTPS from socket to response
Step 1: DNS resolves example.com to 192.0.2.1. Step 2: TCP establishes with SYN, SYN-ACK, ACK, negotiating sequence numbers and MSS. Step 3: TLS 1.3 needs one round trip: the ClientHello already carries key_share and supported ciphers such as TLS_AES_128_GCM_SHA256, the server replies with its certificate and Finished; ALPN advertises h2 so HTTP/2 framing is agreed before any byte of HTML moves. Step 4: the request GET /index.html with :authority: example.com travels encrypted, and the server answers 200 OK with content-type: text/html. The client, not the network, validates certificates: a browser rejects a chain that does not reach a trusted root or whose name does not match. HSTS (max-age=63072000; includeSubDomains) prevents downgrade to plaintext, and OCSP or CRL tell you a key was revoked after issuance.
Email rides the same stack with different protocols
Mail uses store-and-forward between servers instead of a client-to-server fetch. A MUA submits to its provider over port 587 with STARTTLS, or 465 for implicit TLS; the provider's MTA then relays MTA-to-MTA on port 25 using EHLO, MAIL FROM:<alice@example.com>, RCPT TO:, DATA, ending with QUIT. Retrieval then uses IMAP on 993 or POP3 on 995. Message content is MIME-encoded, and the envelope sender can legitimately differ from the From: header, so trust must be asserted inside the message itself: SPF in a TXT record lists permitted senders, DKIM adds an RSA signature over selected headers, and DMARC ties both together with a policy such as p=reject. TLS protects hops; only these three checks stop header forgery.
Reading the stack as a defender
Ports tell you which layer to fix: 80 versus 443 is an application decision, TLS configuration is a library decision, firewall rules are a layer 3 and 4 decision. Capture with curl -v or openssl s_client -connect example.com:443 to watch each layer.
Architecture Diagram
Key Takeaways
- Each layer adds a header: HTTP inside TLS inside TCP inside IP inside Ethernet.
- MTU
1500minus IP and TCP headers yields an MSS near1460. - TLS 1.3 completes in one round trip, and the client validates the chain and hostname.
- Mail uses submission
587, relay25, and retrieval993or995. - SPF, DKIM, and DMARC are what authenticate email; TLS alone does not.