How TLS/HTTPS Works: Securing the Internet's Traffic

TLS (Transport Layer Security) is the cryptographic protocol that secures nearly all internet communication. When you see the padlock icon in your browser or a URL beginning with https://, TLS is encrypting the data between your device and the server. Without TLS, every password you type, every page you load, and every API call your apps make would travel across the internet in plain text — readable by anyone with access to the network path.

TLS operates at the transport layer, sitting between TCP and application protocols like HTTP. When HTTP runs over TLS, we call it HTTPS (HTTP Secure). But TLS is not limited to web traffic — it secures email (SMTPS, IMAPS), DNS over HTTPS, VPN connections, and virtually any TCP-based protocol.

Why Encryption Matters: The Problem TLS Solves

Internet traffic passes through many networks between source and destination. When you look up an IP address like 8.8.8.8 in the looking glass, you can see the AS path — a chain of autonomous systems the traffic traverses. Each of these networks, and every router along the way, could in principle inspect unencrypted traffic. Your ISP, a public internet exchange point, a compromised router, or a state-level actor sitting on a backbone link — all are potential eavesdroppers.

TLS provides three fundamental guarantees:

• Confidentiality — data is encrypted so only the intended recipient can read it
• Integrity — any modification of data in transit is detected and rejected
• Authentication — the server proves its identity via a certificate, preventing impersonation

These properties together prevent man-in-the-middle (MITM) attacks, where an attacker intercepts and potentially alters communication between two parties. This is especially important given threats like BGP hijacks, where an attacker can reroute traffic through their network — TLS ensures that even hijacked traffic remains unreadable and tamper-proof.

Public Key Cryptography: The Foundation

TLS relies on two distinct kinds of cryptography, each serving a different purpose. Understanding the difference is essential to understanding the handshake.

Asymmetric (public key) cryptography uses a mathematically linked pair of keys: a public key that anyone can know, and a private key that only the owner possesses. Data encrypted with the public key can only be decrypted with the private key, and vice versa. The two dominant algorithms are RSA (based on the difficulty of factoring large integers) and ECDH/ECDSA (based on elliptic curve mathematics, offering equivalent security with much smaller keys). Asymmetric cryptography is computationally expensive — roughly 1,000 times slower than symmetric encryption.

Symmetric cryptography uses a single shared key for both encryption and decryption. It is fast — modern CPUs have dedicated AES instructions (AES-NI) that encrypt at gigabytes per second. The two standard ciphers in TLS today are AES-GCM (AES in Galois/Counter Mode, providing both encryption and authentication) and ChaCha20-Poly1305 (a stream cipher designed by Daniel Bernstein, preferred on devices without hardware AES support).

TLS uses asymmetric cryptography to establish a shared secret, then switches to symmetric cryptography for the actual data transfer. This gives you the authentication properties of public key crypto with the speed of symmetric ciphers.

The TLS Handshake: Establishing a Secure Connection

Before any encrypted data can flow, the client and server must perform a TLS handshake. This handshake negotiates the protocol version, selects cipher suites, authenticates the server, and derives the symmetric keys used for encryption. The handshake is the most complex part of TLS, and it changed significantly between TLS 1.2 and TLS 1.3.

TLS 1.3 Handshake (Current Standard)

TLS 1.3, defined in RFC 8446 (2018), dramatically simplified and sped up the handshake. It completes in a single round-trip (1-RTT), compared to two round-trips in TLS 1.2. Here is what happens:

1. Client Hello — The client sends its supported cipher suites, a random value, and key shares for one or more key exchange algorithms. In TLS 1.3 the client speculatively generates key shares upfront (usually for X25519 or P-256 elliptic curves), eliminating a round trip.
2. Server Hello + Encrypted Extensions — The server selects a cipher suite and key share, sends its own random value, and immediately starts encrypting. The server sends its certificate, a certificate verify signature, and a Finished message — all encrypted.
3. Client Finished — The client verifies the server's certificate and signature, sends its own Finished message, and begins sending encrypted application data.

TLS 1.3 removed support for older, less secure algorithms. Only five cipher suites are allowed, all using AEAD (Authenticated Encryption with Associated Data) ciphers. RSA key exchange was removed entirely — only ephemeral Diffie-Hellman (DHE and ECDHE) is allowed, which provides forward secrecy: even if the server's private key is later compromised, past sessions cannot be decrypted.

TLS 1.2 vs TLS 1.3

TLS 1.2 (RFC 5246, 2008) served the internet well for a decade, but had accumulated significant complexity and security risks. Key differences:

• Round trips — TLS 1.2 requires 2-RTT for a full handshake; TLS 1.3 requires 1-RTT. On a connection with 50ms latency, this saves 50ms before the first byte of data can flow.
• Cipher suite explosion — TLS 1.2 supported over 300 cipher suites, many insecure (RC4, DES, export-grade ciphers). TLS 1.3 has exactly 5, all based on AEAD ciphers.
• RSA key exchange — TLS 1.2 allowed static RSA key exchange, where the same server key decrypts all sessions. If that key is compromised, all past traffic is compromised. TLS 1.3 mandates ephemeral key exchange for forward secrecy.
• Handshake encryption — In TLS 1.2, the entire handshake (including the server certificate) is sent in the clear. In TLS 1.3, everything after Server Hello is encrypted, hiding the certificate from passive observers.
• Removed features — TLS 1.3 removed compression (which enabled the CRIME attack), renegotiation (which enabled various attacks), and custom DHE groups (which enabled the Logjam attack).

0-RTT Resumption in TLS 1.3

TLS 1.3 introduced 0-RTT (zero round-trip time) resumption. When a client has previously connected to a server, it can store a pre-shared key (PSK) from that session. On reconnection, the client can send encrypted application data in its very first message, before the handshake completes. This eliminates the handshake latency entirely for repeat visits.

The tradeoff is security: 0-RTT data is vulnerable to replay attacks. An attacker who captures the Client Hello can replay it, causing the server to process the early data twice. For this reason, 0-RTT should only be used for idempotent requests (like GET) and servers must implement replay protection.

Server Name Indication (SNI) and ALPN

SNI (Server Name Indication) is a TLS extension that allows the client to specify which hostname it is connecting to during the handshake. This is critical for shared hosting and CDNs where hundreds of domains share a single IP address. Without SNI, the server would not know which certificate to present.

In standard TLS 1.3, the SNI field in Client Hello is unencrypted, meaning a network observer can see which domain you are connecting to even though the page content is encrypted. Encrypted Client Hello (ECH), still being standardized, will encrypt the SNI field as well.

ALPN (Application-Layer Protocol Negotiation) is another TLS extension that lets the client and server agree on the application protocol (HTTP/1.1, HTTP/2, HTTP/3) during the handshake, avoiding a separate negotiation step after TLS is established.

Certificate Authorities and the Chain of Trust

When a server presents its TLS certificate during the handshake, the client must verify that the certificate is legitimate. It does this by checking a certificate chain — a sequence of certificates linking the server's certificate back to a trusted root.

The chain works as follows:

1. A Certificate Authority (CA) like Let's Encrypt, DigiCert, or Google Trust Services generates a root certificate. This root certificate's public key is pre-installed in your operating system and browser (the "trust store").
2. The root CA issues an intermediate certificate, signing it with the root's private key. The root key is kept offline in hardware security modules for protection — the intermediate handles day-to-day issuance.
3. The intermediate CA issues the leaf certificate (also called end-entity certificate) for a specific domain like god.ad, signing it with the intermediate's private key.
4. The server sends its leaf certificate and the intermediate certificate. The client verifies each signature up the chain until it reaches a root in its trust store.

If any link in this chain is invalid — the signature does not verify, the certificate has expired, or the domain does not match — the connection fails and your browser shows a certificate error. This is the system that prevents an attacker from presenting a fake certificate for google.com — they would need a CA to sign it, and CAs are supposed to verify domain ownership before issuing certificates.

Certificate Transparency

The CA system has a fundamental weakness: there are over 100 root CAs trusted by major browsers, and any of them can issue a certificate for any domain. If a CA is compromised or coerced, it could issue a fraudulent certificate. This has happened — in 2011, the Dutch CA DigiNotar was breached and attackers issued fake certificates for Google, which were used to intercept Gmail traffic in Iran.

Certificate Transparency (CT), defined in RFC 6962, addresses this by requiring CAs to publicly log every certificate they issue. These logs are append-only, cryptographically verifiable data structures (Merkle trees). Anyone can monitor the logs for certificates issued for their domain. Browsers now require CT log entries for new certificates — a certificate without CT log proof will not be accepted.

CT does not prevent mis-issuance, but it makes it detectable. Domain owners can set up monitoring to be alerted within minutes if any CA issues an unexpected certificate for their domain.

OCSP and Certificate Revocation

When a certificate's private key is compromised or a certificate is mis-issued, it needs to be revoked before its expiration date. Two mechanisms exist:

• CRL (Certificate Revocation List) — the CA publishes a list of revoked certificate serial numbers. This list can grow very large, and clients must download and check it, making it impractical at scale.
• OCSP (Online Certificate Status Protocol) — the client asks the CA's OCSP responder "is certificate serial number X still valid?" and gets a signed yes/no answer. This is more efficient than CRLs but has privacy implications (the CA learns which sites you visit) and availability problems (if the OCSP responder is down, what should the client do?).

OCSP Stapling solves both problems: the server periodically fetches its own OCSP response from the CA and "staples" it to the TLS handshake. The client gets a fresh, CA-signed proof of validity without ever contacting the CA. TLS 1.3 encourages OCSP stapling via the status_request extension.

In practice, modern browsers use a combination approach. Chrome, for instance, uses CRLSets — a curated, compressed set of revoked certificates pushed via browser updates — rather than relying on OCSP for most certificates.

HSTS: Forcing HTTPS

HTTP Strict Transport Security (HSTS) is a mechanism that tells browsers to always use HTTPS for a domain, even if the user types http:// or clicks an HTTP link. The server sends the header Strict-Transport-Security: max-age=31536000; includeSubDomains, and the browser remembers this directive for the specified duration.

HSTS prevents SSL stripping attacks, where a MITM attacker intercepts the initial HTTP request (before the redirect to HTTPS) and presents an unencrypted version of the site to the victim while maintaining their own encrypted connection to the real server. With HSTS in effect, the browser will never send an unencrypted request to the domain.

The HSTS preload list takes this further — domains can be hardcoded into the browser's source code so that HTTPS is enforced from the very first visit, before any HSTS header has ever been received. Major sites like Google, Facebook, and Twitter are on the preload list.

How HTTPS Prevents Man-in-the-Middle Attacks

HTTPS with TLS defeats MITM attacks at multiple layers:

• Authentication — The server's certificate, signed by a trusted CA, proves its identity. An attacker cannot forge this without compromising a CA.
• Key exchange — ECDHE key exchange ensures that even if the attacker can observe the handshake, they cannot derive the session keys without the private key material, which never crosses the network.
• Encryption — AES-GCM or ChaCha20-Poly1305 encrypts all data, making intercepted traffic unreadable.
• Integrity — AEAD ciphers include a Message Authentication Code (MAC) with every record. Any modification of ciphertext is detected and the record is rejected.
• Forward secrecy — Ephemeral key exchange means each session uses unique keys. Compromising the server's long-term key does not compromise past sessions.

This is why TLS is critical in the context of BGP security. A BGP hijack can reroute traffic through an attacker's network, but if that traffic is encrypted with TLS, the attacker still cannot read or modify it. They can disrupt connectivity (by dropping packets), but they cannot silently intercept the content. TLS transforms a routing-level attack into a denial-of-service at worst, rather than a full compromise of confidentiality.

TLS and DNS: Closing the Last Gap

Even with HTTPS securing web traffic, DNS queries traditionally travel unencrypted. An attacker who can see your DNS traffic knows which sites you are visiting, even if they cannot see the page content. DNS over HTTPS (DoH) and DNS over TLS (DoT) close this gap by encrypting DNS queries using the same TLS infrastructure.

The combination of HTTPS, DoH, and Encrypted Client Hello (ECH) moves toward a future where the only metadata visible to a network observer is the IP addresses of the communicating parties — and even those are routable via anycast CDN addresses shared across millions of sites.

See It in Action

TLS protects traffic, but the underlying network routing is visible through BGP. You can use the looking glass to see how traffic reaches the infrastructure that powers TLS — the certificate authorities, CDN providers, and DNS resolvers:

• AS13335 — Cloudflare, which provides TLS termination for millions of websites
• AS16509 — Amazon Web Services, hosts ACM (Amazon Certificate Manager)
• AS396982 — Google Trust Services, a major certificate authority
• 1.1.1.1 — Cloudflare's DNS resolver, reachable via DoH at https://cloudflare-dns.com/dns-query
• 8.8.8.8 — Google Public DNS, reachable via DoH at https://dns.google/dns-query

Every HTTPS connection to this very page was secured by TLS — the handshake negotiated a cipher suite, the server's certificate was validated up the chain to a trusted root, and the page content was encrypted with a unique session key. Look up any website's IP in the looking glass to see the AS path your encrypted traffic traverses on its way to the server.