Building Trust on the Internet — Part 1: From First Principles to HTTPS

How does a browser securely talk to a server it has never met before over a network that anyone can intercept?

This question sits at the heart of HTTPS. There’s no shared secret, the network is untrusted, and attackers can read or modify packets. Yet, every day our browser establishes secure connections in milliseconds.

This article builds that system from first principles starting with basic cryptography and ending with modern TLS handshake.

---

1. The Building Blocks

1.1 Symmetric Encryption - Fast but problematic

Symmetric encryption uses the same key for encryption and decryption.

• Example algorithm: AES

• Strength: extremely fast and is used for large data

• Problem: the same key needs to be there with receiver. How to send the key securely?

  • If we already had a secure way to share the key, why not just use that to send the data?

---

1.2 Asymmetric Encryption - Solving Trust, not speed

Asymmetric encryption introduces key pairs:

• Public key (shared openly)

• Private key (kept secret)

Two different keys, different uses

• Encrypt using public key → Decrypt using private key

  • Purpose: Confidentiality

• Sign using private key → Verify using public key (Digital Signatures)

  • Purpose: Authenticity + Integrity

Asymmetric encryption is not used for bulk data since it’s too slow. It’s used to establish trust and identity

---

1.3 Hashing ensures integrity

A hash function (like SHA-256)

• Takes in input of any size

• produces fixed length output

• is deterministic

• is irreversible

Why Hashing?

To verify data integrity

If HASH(data1) == HASH(data2), then data1 == data2

---

2. Digital Signatures

Digital signature combines Hashing and asymmetric encryption

Let’s define:

• HASH(k) → hash of data k

• Sign(pvt, k) → sign using private key

• Verify(pub, sig, k) → verify using public key

---

Signing

h = HASH(k) , sig = Sign(pvt, h)

---

Verification

h1 = HASH(k), h2 = Verify(pub, sig)

if: h1 == h2 → trusted source

---

What does this give us?

• Integrity → data wasn’t changed while it reached destination

• Authenticity → signed by owner of private key

---

3. The Real Problem: Trust

At this point, we can verify signatures, but the bigger problem is:

How do we trust a public key?

Anyone can generate a (pub, pvt) key pair

So how do we know if the key actually belongs to example.com?

---

4. Public Key Infrastructure (PKI)

PKI solves the trust problem using hierarchy:

• Root Certificate Authority (RCA)

• Intermediate Certificate Authority (ICA)

• Web Servers (Websites)

---

Key Concepts

• Certificate → binds identity + public key

• CA → entity that signs certificates

  • ICA → Intermediate Certificate Authority

  • RCA → Root Certificate Authority

• Chain of Trust → Layered verification

---

How are certificates Issued

The diagram above shows how websites prepare for building trust among browsers (or User Agents) to be able to securely connect to them. To understand the flow, read the diagram from right to left.

Lets dig in deeper:

• pub → public key

• pvt → private key

• HASH(k) → hash function

• Sign(pvt, k) → signature

---

Step 1 : ICA gets signed certificate from Root CA

ICA generates:

ICA.pub, ICA.pvt

ICA sends a CSR (Certificate Signing Request) to Root CA.

Root CA:

h = HASH(ICA.pub)
sig = Sign(RCA.pvt, h)

Returns certificate:

(ICA.pub, sig)

---

Step 2: Server gets signed by ICA

Web Server (WS) generates:

WS.pub, WS.pvt

Sends CSR to ICA.

ICA:

h = HASH(WS.pub)
sig = Sign(ICA.pvt, h)

Returns:

WS Certificate:
  WS.pub
  Sign(ICA.pvt, HASH(WS.pub))

+ ICA Certificate:
  ICA.pub
  Sign(RCA.pvt, HASH(ICA.pub))

---

Result: Chain of Trust

Root CA → ICA → Web Server

---

6. How the Browser Verifies Trust

The browser (or OS) already contains trusted Root CA public keys.

---

Verification Flow

Step 1: Verify ICA

Verify(RCA.pub, ICA.signature)

If valid → browser now trusts ICA

---

Step 2: Verify Server

Verify(ICA.pub, WS.signature)

If valid → browser now trusts the web server (Bob)

---

7. TLS Handshake — Establishing a Secure Session

Now that trust is established, we need a shared symmetric key.

---

Old Approach (RSA Key Exchange)

• Client generates symmetric key

• Encrypts with server public key and sends to server

• Server decrypts using private key

Problem

If attacker gets server private key later:
→ past sessions can be decrypted

---

Modern Approach: Diffie-Hellman (ECDHE)

Instead of sending the key, both sides derive it independently.

\((g^a\ mod\ p)^b≡(g^a)^b\ mod\ p\)

Intuition

• Both sides agree on g and p

• Client picks secret a

• Server picks secret b

Exchange:

Client → g^a mod p
Server → g^b mod p

Then:

Client computes: (g^b)^a mod p
Server computes: (g^a)^b mod p

Both get:

\(g^{(ab)}\ mod\ p\)

Key Insight

The shared secret is never transmitted.

Why this is powerful

• Provides Forward Secrecy

• Even if private key is compromised later:
  → past sessions remain secure

---

8. Final TLS Flow (Putting Everything Together)

1. Browser connects to server

2. Server sends certificate chain

3. Browser verifies:

   • Root → ICA

   • ICA → Server

4. Trust is established

5. Client & server perform ECDHE key exchange

6. Shared symmetric key is derived

7. All further communication uses symmetric encryption (AES)

---

9. Why This Design Works

This system combines:

• Asymmetric crypto → identity & trust

• Hashing → integrity

• Signatures → authenticity

• PKI → global trust system

• Diffie-Hellman → secure key exchange

• Symmetric crypto → performance

---

10. Final Mental Model

Think of HTTPS as:

• Certificates → prove identity

• Signatures → prove authenticity

• PKI → establish trust

• TLS handshake → agree on secret

• AES → secure communication

---

Closing Thoughts

What looks like a simple 🔒 in our browser is actually:

• a distributed trust system

• built on cryptography

• standardized through PKI

• and optimized over decades

In this article, we built the foundation:

• Asymmetric cryptography → identity and signatures

• Hashing → integrity

• PKI → global trust

• TLS → secure communication channel

But this only solves one part of the problem.

TLS ensures we are talking securely to a server.
It does not answer who the user is or what they are allowed to do.

---

What Comes Next

Once a secure channel is established, modern systems need to answer two critical questions:

1. Who is the user? (Authentication)

2. What is the user allowed to do? (Authorization)

In the upcoming articles, we’ll build on this foundation and explore how real-world systems solve these problems:

• JWT (JSON Web Tokens)
  → How identity is represented and verified across services

• JWKS (JSON Web Key Sets)
  → How public keys are distributed and rotated at scale

• OAuth
  → How applications securely delegate access

• Authorization Models

  • Role-Based Access Control (RBAC)

  • Attribute-Based Access Control (ABAC)

  • Policy-Based Access Control

• Real-World Systems like AWS IAM
  → How these concepts come together in production systems

---

The Bigger Picture

If TLS answers:

“Can we trust this server and communicate securely?”

Then the rest of the system answers:

“Can we trust this user, and what are they allowed to do?”

---

By the end of this series, we won’t just understand individual concepts like JWT or OAuth in isolation—we’ll understand how they fit together into a complete, real-world authentication and authorization system.