Synthesis: Tracing gmail.com

This is the synthesis exercise from Session 5. Work through it yourself first — try to answer each question before reading the answer below it. The goal is to connect every concept from Sessions 1 through 4 into one coherent walkthrough.

The scenario: Deepa has a brand new phone. She connects to the college Wi-Fi, opens Chrome, and types gmail.com into the address bar. She presses Enter.

Trace everything that happens — from that keypress to the moment her inbox loads.

Step 1 — DNS Resolution

Question: Deepa typed gmail.com. Her browser does not know where gmail.com is. What is the very first thing it does?

Answer:

Her browser makes a DNS lookup for gmail.com. This query goes to the DNS resolver configured on the college Wi-Fi — usually the ISP’s resolver.

The resolver checks its cache: “Have I looked up gmail.com recently?” If not, it queries up the DNS hierarchy — the root servers, then Google’s authoritative name servers — until it gets an answer.

The answer comes back: an IP address like 142.250.192.83. Her browser now knows where to send the request.

Without this step, nothing else can happen. DNS is the foundation.

Concepts used: DNS, name resolution, DNS hierarchy, DNS cache — Session 1

Step 2 — Connecting to Port 443

Question: The browser has the IP address. It wants to connect to Gmail. Which port does it use, and why?

Answer:

The browser connects to 142.250.192.83 on port 443.

Port 443 is the standard port for HTTPS. The browser knows to use it because the URL is https://gmail.com — Chrome automatically adds https:// for well-known sites, and Gmail enforces HTTPS through HSTS (which we will cover in Step 6).

On the other end of port 443 sits a server process — Google’s web server software — that is listening for incoming HTTPS connections. The browser is not talking to a person or a building. It is talking to software running in Google’s data centre.

Concepts used: Ports, server processes, TCP/IP stack (Transport layer), HTTPS — Session 1

Step 3 — TLS Handshake and Encryption

Question: Before any Gmail data is sent, the browser and server negotiate an encrypted connection. How?

Answer:

The browser and Google’s server run the TLS handshake:

  1. Browser: “I want a secure connection. I support TLS 1.3.”
  2. Server: “Here is my certificate. Here is my public key.”
  3. Browser: verifies the certificate (Step 4), then uses the server’s public key to agree on a shared secret
  4. Both sides derive a symmetric session key from that shared secret
  5. All subsequent data — Gmail’s HTML, Deepa’s login credentials, her emails — is encrypted with this session key

Asymmetric encryption (public/private key pair) was used to securely exchange the session key. Symmetric encryption (AES) is used for all the actual data. This hybrid approach gives both security and speed.

Concepts used: TLS handshake, asymmetric encryption, symmetric encryption, session key — Session 2

Step 4 — Certificate Verification

Question: How does Deepa’s browser know it is actually talking to Gmail’s server — and not an impersonator?

Answer:

The browser validates Gmail’s digital certificate:

  1. It reads the certificate: Subject: mail.google.com, Issuer: Google Trust Services
  2. It hashes the certificate and checks the CA’s digital signature — if the hash matches, the certificate has not been tampered with
  3. It walks the chain of trust: Google Trust Services → a Root CA that is pre-installed in Android’s certificate store
  4. It verifies the Root CA is trusted (pre-installed by Google on her phone)
  5. It checks the domain: mail.google.com matches gmail.com (Google uses multiple domains)
  6. It checks expiry: the certificate is still valid today

All six checks pass. The TLS handshake continues. The encrypted session is established.

If any check had failed, the browser would have shown a NET::ERR_CERT_* error and refused to continue.

Concepts used: Hashing, digital signatures, certificates, certificate chain, chain of trust, Root CA, certificate store — Session 3

Step 5 — Browser Certificate Store

Question: Why does Deepa’s brand new phone — which has never visited Gmail before — already trust Google Trust Services?

Answer:

Because Google pre-installed approximately 150 Root CA certificates on every Android phone before it left the factory. One of those pre-installed certificates is Google Trust Services (or the root it chains to).

Deepa did not configure this. She did not approve these CAs. They were installed by Google as part of the Android operating system. When she bought the phone, those trusted CAs were already there.

This is what makes the certificate system work at scale. No one could manually approve CAs for every site they visit. The trust comes pre-installed by the platform provider (Google for Android, Apple for iOS, Microsoft for Windows), backed by the auditing those companies do on CAs before including them.

Concepts used: Browser/device certificate store, pre-installed Root CAs, certificate trust model — Session 4

Step 6 — HSTS Enforcement

Question: Deepa only typed gmail.com — not https://gmail.com. How does her browser know to use HTTPS?

Answer:

Two mechanisms work together:

Chrome’s auto-HTTPS: Chrome automatically upgrades known domains to HTTPS. For well-known sites like Gmail, it starts with HTTPS directly.

HSTS (HTTP Strict Transport Security): When Gmail’s server responds, it includes a header: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

This tells the browser: “For the next year (31,536,000 seconds), never connect to gmail.com or any of its subdomains over plain HTTP. Always use HTTPS.”

From this point forward, Deepa’s browser has saved that instruction. If she ever types just gmail.com again — or even if someone on the network tried to redirect her to an HTTP version of Gmail — her browser refuses. It goes straight to HTTPS without making any HTTP request at all.

Gmail is also on the HSTS preload list — a list compiled directly into Chrome’s source code. Even on a fresh browser that has never visited Gmail, HSTS is already in effect.

Concepts used: HSTS, browser security policies, HTTPS enforcement — Session 4

Full Picture

Deepa types gmail.com → Enter
      ↓
Step 1: DNS resolves gmail.com → 142.250.x.x          [Session 1]
      ↓
Step 2: TCP connects to port 443 (HTTPS port)          [Session 1]
        Server process answers (Google's web server)
      ↓
Step 3: TLS handshake — asymmetric key exchange        [Session 2]
        → Symmetric session key established
        → All data now encrypted with AES
      ↓
Step 4: Certificate validated — Google Trust Services  [Session 3]
        Hash verified → chain of trust walked
        Domain match ✓ | Expiry ✓ | Revocation ✓
      ↓
Step 5: Root CA trusted — pre-installed on Android     [Session 4]
        No manual approval needed
      ↓
Step 6: HSTS enforced — browser saves "always HTTPS"   [Session 4]
        Future visits go straight to HTTPS
      ↓
Gmail inbox loads — encrypted, verified, enforced

Six steps. Every session contributed one. That is the course.

Every time Deepa opens Gmail — on any device, on any network — these six steps run automatically. Understanding them means understanding how the internet actually works.