How HTTPS Works — From Shared Wires to TLS

This guide is written for someone who does not yet live inside protocol names. By the end you should tell the full story — in order — of how a browser reaches a website over the shared Internet, from packets through TCP and TLS to encrypted HTTP.

Learning goals

• Explain packet switching vs a dedicated physical line
• Walk TCP handshake → TLS → first HTTPS request without mixing layers
• Separate cookies from TLS keys, and DROP vs REJECT firewall behavior

This is the core foundation of the course. Read top to bottom the first time (do not skip to TLS).

This guide is written for someone who does not yet live inside protocol names. New terms are introduced only when you need them, with a plain-English meaning first and the technical name second. By the end you should be able to tell the story in order: what happens first, what happens next, and why.

How to read this

Read from top to bottom the first time. Skipping ahead will put you in the middle of acronyms before you have the mental picture. After one pass, use the glossary at the bottom as a cheat sheet.

Part 1 — The situation (no protocols yet)

Imagine your laptop and some company’s computer (a server) want to exchange data — for example, “give me the home page” and “here is the HTML.”

They are not connected by a private wire between your desk and their data center. Your message leaves your house over Wi‑Fi or Ethernet, passes through many devices and links (router, ISP, backbone routers, the server’s network), and each hop is shared with other people’s traffic.

So the first mental model is:

• There is one big shared system (the Internet).
• Your conversation is one of millions happening at the same time.
• The network’s job is to get your chunks of data to the right machine, and the right program on that machine, mostly without mixing them up with everyone else’s.

Everything below is just rules so that “chunks” can be labeled, delivered, checked, and (with HTTPS) protected.

Part 2 — Chunks, not a continuous hose

When people say “a connection,” it is easy to imagine a hose of bytes flowing continuously through a tube that only you own. In reality the Internet almost always works like postal packets:

• Your data is cut into small pieces (often called packets).
• Each piece has labels on it: roughly “from where,” “to where,” and “this is piece 3 of 10.”
• Those pieces ride on shared infrastructure. Different pieces might even follow slightly different paths and arrive out of order. The system is built for that.

Packet switching means: links and routers are not reserved for your call alone. They carry many people’s packets interleaved. That is efficient: nobody’s cable sits idle while you read a page.

Circuit switching (older telephone style, simplified) meant: a path could be reserved end-to-end for the duration of a call, even when nobody was speaking. Good for predictable voice; wasteful for bursty computer traffic.

So when someone asks: “Do we get a dedicated line with TCP?” the accurate picture is:

• No — there is usually no physical line reserved only for you.
• Yes, it can feel like a line — because the software on both sides cooperates so that your application sees an ordered, continuous stream of bytes even though underneath it is packets on shared paths.

That “feeling of a line” is a logical connection: an agreement between two programs, not a private cable.

Part 3 — Addresses: how the network picks the right computer

Each machine on the network has an IP address — think “street address for a building” at the network layer. IPv4 looks like 203.0.113.10; IPv6 is longer. Routers use these addresses to forward packets toward the destination.

One computer runs many programs that talk to the network (browser, mail, updates). So we need one more label: a port number (an integer). Think “apartment number inside the building.” A web server usually listens on port 443 for HTTPS and port 80 for HTTP.

Important for later: “Connecting to a private IP in a VPC” means: your packets are addressed to an IP that only exists inside someone else’s private network. From the public Internet, that address is often not routable or is blocked by firewalls. Your software still tries to send packets; what comes back (or does not) depends on the rules below.

Part 4 — Two famous ways to send: TCP and UDP (names last)

Your operating system exposes sockets to programs: “open a channel to this IP and this port.” The two most common choices are TCP and UDP. Both ride on top of IP (Internet Protocol), which handles routing to the address.

TCP — “I need a reliable conversation”

TCP stands for Transmission Control Protocol.

What it promises (in plain words):
If you send a stream of bytes to the other side using TCP, the stack on both ends tries very hard to give you: all bytes, in the right order, without duplicates, and it signals errors when the conversation cannot be opened.

How it does that (ideas before jargon):

1. “Are we both ready to talk?” — Before your app’s data normally flows, the two sides run a small opening ritual so both know the channel is open and initial numbers are agreed. Technically this is the three-way handshake:

   • Client → Server: SYN (“synchronize”; I want to start and here is my starting number”).
   • Server → Client: SYN-ACK (“I agree, and here is my starting number”).
   • Client → Server: ACK (“I got yours; we are open for business.”)

2. “What order do these belong in?” — Every byte stream is tracked with sequence numbers. If pieces arrive out of order, TCP reorders them before handing them to your app.

3. “Did you get it?” — The receiver sends acknowledgements (ACK). If the sender does not see progress, it sends again (retransmission).

So TCP creates a reliable byte pipe between two ports over a messy, shared network.

Where does TCP “live” in the classic layered picture? People often call it transport layer (roughly “layer 4” in the OSI-style stack). IP is below (routing). HTTP and TLS are above (application-ish layers — exact diagrams vary, but “above TCP” is enough).

Virtual circuit: Some books say TCP behaves like a virtual circuit — meaning it acts like a dedicated circuit for your bytes, even though underneath it is packet switching. The behavior is “circuit-like”; the physical world is still shared packets.

UDP — “I will fire messages; I won’t babysit each one”

UDP stands for User Datagram Protocol.

What it promises:
Very little. You send datagrams (discrete messages). UDP does not open a formal “ready?” session like TCP. It does not reorder a long stream for you or retransmit by itself.

Analogy: TCP is like a tracked courier with delivery confirmation. UDP is like dropping postcards in a mailbox: they probably arrive, but you are not guaranteed a reply, and you might not know if one was lost.

Part 5 — “I tried to reach a private VPC IP” — who notices, and when?

Suppose your code tries to reach an address that is not reachable from where you sit (private cloud network, wrong route, or firewall).

With TCP

TCP must complete its opening ritual to consider the connection established. So your program usually learns something is wrong:

• Something might answer “go away” with a TCP reset (RST), or the network might return an ICMP message (a control message meaning “unreachable” in various situations). Your library might show connection refused or a similar error (exact text depends on language and OS).

• Or a firewall might drop your packets: no answer at all. Then your TCP stack waits and eventually times out. You still get a failure, but slower.

So TCP tends to give a clear failure (fast refusal or slow timeout). Your app can say: “we did not connect.”

With UDP

You often send a UDP packet and the API returns success when the operating system accepted the packet to send — not when the other app received it.

If the packet is dropped silently on the path, you might never know unless:

• the network sends an ICMP error that your stack surfaces, or
• your own application protocol adds ACKs and timeouts (like how a game or video protocol might).

Firewall rule styles (the REJECT vs DROP idea)

• REJECT (conceptually): “Tell the sender no” — may generate an ICMP or TCP RST style response. Both TCP and UDP situations can become more visible to software.

• DROP: “Say nothing” — the packet vanishes. TCP usually ends in timeout. UDP often looks like “I sent it” even though nothing useful arrived.

About ping: ping uses ICMP, not TCP or UDP. Whether ping works does not prove a web port is open; admins often block ping but allow HTTPS, or the opposite. Treat it as a hint, not proof.

Part 6 — HTTP: what the browser and server actually say

HTTP (Hypertext Transfer Protocol) is the language of requests and responses for the web: “GET this path,” “here is status 200,” “here is HTML,” headers, cookies, and so on.

By itself, HTTP is plain text (for the application content). Anyone who can read the traffic between your Wi‑Fi and the next hops can read passwords, cookies, page content if you use raw HTTP. That matters on coffee shop Wi‑Fi (Part 10).

Part 7 — HTTPS: HTTP inside a protective tunnel (introducing TLS)

HTTPS is not a different HTTP grammar. It is normal HTTP, but the bytes travel inside an encrypted tunnel created by TLS.

TLS stands for Transport Layer Security (older docs say SSL). TLS provides roughly:

• Encryption — observers see gibberish, not your headers and body.
• Integrity — tampering is detectable.
• Authentication of the server — usually via an X.509 certificate chain tied to a domain, so your browser can check “this really is example.com’s server,” not an impostor.

TLS sits on top of TCP: first the two ends establish a reliable TCP channel, then they run the TLS handshake inside that channel to agree on keys and algorithms.

Phone-call analogy:

• TCP — You dial, someone answers “Hello?” The call exists.
• TLS — You then agree on a secret code for the rest of the call.
• HTTP — The actual conversation (“send me the page”) happens after TLS is ready, and those HTTP bytes are encrypted by TLS.

Part 8 — “Do we exchange public keys during SYN/ACK?”

No. The SYN, SYN-ACK, and ACK messages belong to TCP only. They carry no TLS certificates and no public keys. TCP is not aware of encryption; it just moves bytes.

Public keys show up when TLS starts, after TCP is up. The server presents a certificate; inside that structure is the server’s public key (and signatures proving the certificate is issued by a trusted authority your browser already knows).

Rough order (simplified):

1. TCP three-way handshake completes → a reliable pipe exists.
2. TLS ClientHello → client offers TLS versions and crypto options.
3. TLS ServerHello + certificate (server identity and public key material) + key exchange messages.
4. Both sides compute shared secret material and derive session keys.
5. Finished messages — each side proves it derived the same keys.
6. Application data — now HTTP requests and responses flow encrypted.

Part 9 — “So the client encrypts everything with the server’s public key?”

Not the big stream of your browsing. Public-key cryptography is powerful but heavy. Encrypting every byte of a Netflix session or a large API response with only the server’s public key would be slow.

Instead, TLS uses a hybrid design:

1. Asymmetric cryptography (public/private keys, certificates) is used heavily in the handshake to authenticate and to run a key exchange so both sides arrive at shared secret bytes without just shouting a password in the clear.

2. Those shared bytes are fed through standardized key derivation to produce session keys — symmetric keys (both sides know the same secret for this session).

3. Bulk data (HTML, JSON, images) is encrypted with these fast symmetric algorithms (modern TLS uses ciphers like AES-GCM or ChaCha20-Poly1305 at the record layer — names you can look up later).

4. Finished messages at the end of the handshake prove both sides agree on the derived keys.

Chain to remember:

TCP opens the pipe → TLS agrees keys and checks identity → HTTP flows inside TLS (that combination is HTTPS).

TLS 1.3 is a newer version of TLS that needs fewer round trips for a cold start than older TLS 1.2 in many cases. The story is the same: TCP first, then TLS, then symmetric-protected application data.

Part 10 — “Does the full dance happen on every single HTTPS request?”

Usually not, after the first setup on a connection.

Same TCP + TLS connection, many HTTP requests

Browsers and servers often use HTTP keep-alive: keep the same TCP connection (with TLS already established) and send many HTTP requests on it. Loading ten images from the same site can reuse one TLS session instead of ten cold starts.

You closed the tab and came back — session resumption

If TCP is gone but the client still has a session ticket (or older session ID), the next visit can use TLS session resumption: a shorter second handshake. Your earlier notes called this a “fast pass.” The client shows a ticket; the server validates it and they re-establish key material efficiently.

Junior-accurate wording: Resumption is still real cryptography; it is not “TLS turned off.” Some informal explanations say “skip the certificate entirely” — think instead: less work than a cold start, not “no security.”

TLS 1.3 and “0-RTT”

TLS 1.3 can allow early data in special 0-RTT modes for returning clients so the first application bytes can go out very quickly. Tradeoff: that early chunk can be replayable by someone on the network unless the application only puts safe, idempotent work in it. Servers and frameworks constrain this for a reason.

Rough scenarios

Part 11 — “If someone steals all my cookies, do they get my TLS keys?”

No — cookies and TLS keys are different things.

• Cookies are data your browser stores and often sends in HTTP headers (for example “here is my logged-in session id”). They are inside the encrypted tunnel when you use HTTPS, but they are still application secrets. If malware or an attacker copies your cookies, they may impersonate you on the website (session hijacking) without ever “breaking” TLS math.

• TLS session keys are computed during the TLS handshake and kept in memory inside the browser’s TLS stack for that connection. They are not the same thing as a session cookie named SESSIONID. Stealing cookies does not automatically give the attacker the ability to decrypt all past TLS traffic they captured from the wire.

Why stealing cookies can still be worse than “listening”:
The attacker might not need to decrypt your traffic. They can log in as you, change settings, send messages — whatever the site allows that user to do.

Forward secrecy (often called perfect forward secrecy in marketing):
With modern ephemeral Diffie–Hellman key exchanges (ECDHE), session keys are not recoverable later from the server’s long-term private key alone. So recording encrypted traffic today and stealing the server key next year usually still does not decrypt those old sessions. (Exact properties depend on cipher suites and implementation.)

Part 12 — Session tickets: not “the AES key in a text file”

When TLS resumes, the browser might hold a session ticket: an opaque blob (random-looking bytes) the server knows how to interpret. Think coat-check ticket: the ticket is not the coat; the attendant uses server-side secrets to map the ticket back to cryptographic state and derive fresh session keys for a new connection.

If a ticket is stolen:

• A passive neighbor on Wi‑Fi still sees TLS ciphertext for unrelated sessions — they do not automatically read everyone’s Gmail.

• An active attacker who presents the ticket to the real server from a context the server accepts might continue a session as you — similar in risk class to stealing a bearer token. Good deployments rotate tickets, bind them to context, or refuse odd resumes.

Your note about IP or device changes: CDNs and servers may decline resumption and force a full handshake when the client looks different (new IP, new fingerprint, missing extensions).

Part 13 — HTTP on public Wi‑Fi (no “S”)

If the site is HTTP only, there is no TLS tunnel. There is no modern key agreement protecting the HTTP bytes.

Someone on the same untrusted Wi‑Fi (or anywhere on the path that can observe plaintext) can often use a tool like Wireshark and read:

• Usernames and passwords if submitted over HTTP
• Cookies in headers (then hijack the session)
• Page content and URLs you visit

With HTTPS, they still see that you sent traffic and some metadata (timing, sizes; sometimes the SNI hostname in cleartext in many deployments — a separate privacy topic), but not the decrypted HTTP body and headers.

Browsers show Not Secure on HTTP because anyone on the path could read or change the page.

VPN note: A VPN encrypts traffic between your device and the VPN provider. On hostile Wi‑Fi, neighbors see VPN ciphertext, not your HTTP. Past the VPN’s exit, if the site is still HTTP, that segment is plain again — you have shifted who you trust, not magically fixed HTTP worldwide.

Glossary (acronyms and names in one place)

Checklist — can you explain each without peeking?

• Internet traffic is shared; packet switching vs a dedicated physical line.
• TCP gives a logical reliable pipe: handshake, sequence numbers, ACKs, retransmit.
• IP vs TCP roles: routing vs reliable delivery; ports pick the program.
• UDP is “send and hope”; why unreachable private IPs feel different from TCP.
• DROP vs REJECT and why UDP can lie quietly.
• HTTP is the web’s message format; HTTPS wraps it in TLS.
• TCP completes before TLS; no public keys in SYN/SYN-ACK/ACK.
• Certificate brings the server’s public key into TLS; TCP does not care.
• Symmetric session keys carry bulk data; public key crypto dominates setup.
• Finished proves matching keys; then encrypted HTTP.
• Keep-alive, session resumption, 0-RTT tradeoffs.
• Cookies ≠ TLS keys; cookie theft → session hijack, not automatic TLS break.
• Session tickets are opaque; server maps ticket → crypto state.
• HTTP on Wi‑Fi is readable; HTTPS hides application plaintext; VPN shifts trust.

Further reading (when you are ready for specs)

• RFC 9293 — TCP architecture and semantics (official).
• RFC 8446 — TLS 1.3 (official).
• Cloudflare: What happens in a TLS handshake? — diagrams alongside the RFCs.

This version prioritizes teaching order over interview Q&A shape. If a sentence used a word you did not know, search the glossary first, then reread the section.

Practice checkpoint

1. Does TCP give you a dedicated physical wire?
   Answer: No — shared packet-switched paths; TCP provides a logical reliable byte stream.

2. In what order do TCP and TLS complete?
   Answer: TCP handshake first, then TLS; no application keys in SYN/SYN-ACK/ACK.

3. Are cookies the same as TLS session keys?
   Answer: No — cookie theft is session hijack at the app layer; TLS keys are separate crypto state.

Interview angles

• Walk TCP three-way handshake → TLS → first HTTPS request without mixing layers.
• DROP vs REJECT and why UDP “fails quietly.”
• Keep-alive, session resumption, and 0-RTT tradeoffs.

Next: DNS — Names to Addresses