Synthesis: Tracing onlinesbi.sbi End-to-End

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 onlinesbi.sbi into the address bar. She presses Enter.

Trace everything that happens — from that keypress to the moment SBI’s net banking page loads.

Step 1 — DNS Resolution (Session 1)

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

Answer:

Her browser makes a DNS lookup for onlinesbi.sbi. 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 onlinesbi.sbi recently?” If not, it queries up the DNS hierarchy — the root servers, then the .sbi TLD servers, then SBI’s authoritative name servers — until it gets an answer.

The answer comes back: an IP address like 103.12.x.x. 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 (Session 1)

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

Answer:

The browser connects to 103.12.x.x on port 443.

Port 443 is the standard port for HTTPS. The browser knows to use it because the URL is https://onlinesbi.sbi — Chrome automatically adds https:// and HSTS enforcement (covered in Step 6) guarantees HTTPS is used.

On the other end of port 443 sits a server process — SBI’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 SBI’s data centre, waiting to receive connections on port 443.

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

Step 3 — TLS Handshake and Encryption (Session 2)

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

Answer:

The browser and SBI’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 — SBI’s page HTML, Deepa’s login credentials, her account details — 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. Deepa’s username and password travel inside this encrypted tunnel — no one on the network path can read them.

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

Step 4 — Certificate Verification (Session 3)

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

Answer:

The browser validates SBI’s digital certificate:

  1. It reads the certificate: Subject = onlinesbi.sbi, Issuer = DigiCert (or whichever CA issued it)
  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: DigiCert Intermediate CA → DigiCert Root CA
  4. It verifies the Root CA is trusted (pre-installed by Google on her phone)
  5. It checks the domain: onlinesbi.sbi matches the Subject on the certificate
  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 (Session 4)

Question: Why does Deepa’s brand new phone — which has never visited onlinesbi.sbi before — already trust DigiCert?

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 DigiCert’s Root CA.

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.

DigiCert Root CA is in her phone’s certificate store — so no warning appears. The connection proceeds.

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 (Session 4)

Question: Deepa only typed onlinesbi.sbi — not https://onlinesbi.sbi. 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 banking sites, it starts with HTTPS directly.

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

This tells the browser: “For the next year, never connect to onlinesbi.sbi over plain HTTP. Always use HTTPS.”

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

HSTS means even http:// is refused. The browser enforces this locally, before any network request leaves her device.

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

Full Picture — All Five Sessions, One Page Load

Deepa types onlinesbi.sbi → Enter
      ↓
Step 1: DNS resolves onlinesbi.sbi → 103.12.x.x            [Session 1]
        Browser checks DNS cache first
      ↓
Step 2: TCP connects to port 443 (HTTPS port)               [Session 1]
        SBI's server process answers on port 443
      ↓
Step 3: TLS handshake — asymmetric key exchange              [Session 2]
        → Symmetric session key established
        → Username/password travel inside encrypted tunnel
      ↓
Step 4: Certificate validated — Subject: onlinesbi.sbi       [Session 3]
        Issuer: DigiCert. Hash verified → chain of trust walked
        Domain match ✓ | Expiry ✓ | Revocation ✓
      ↓
Step 5: DigiCert Root CA in phone's certificate store         [Session 4]
        Pre-installed on Android — no warning shown
      ↓
Step 6: HSTS enforced — browser saves "always HTTPS"         [Session 4]
        Even http:// refused from now on
      ↓
SBI net banking loads — encrypted, verified, enforced

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

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

Live Exercise

Do this right now on your own phone:

  1. Open Chrome and go to https://onlinesbi.sbi
  2. Tap the padlock icon in the address bar
  3. Tap Certificate — read the Subject and Issuer
  4. Find the Root CA at the top of the chain — note its name
  5. Now open your phone’s Settings → Security → Encryption & Credentials → Trusted Credentials
  6. Search for that Root CA in the System list
  7. You have just traced the chain of trust yourself — from the website to your phone’s certificate store

This is not an exercise you read about. This is an exercise you do. The certificate is real. The Root CA is real. The trust chain is the same one your browser walks automatically, every time, on every connection.