Day 11/21: System Design (TLS)

Security is critical in system design, and TLS (Transport Layer Security) ensures data encryption, integrity, and authentication over the internet. When you visit a website like Google, Amazon, or your bank, TLS secures your communication, preventing attackers from intercepting or modifying data.

Today, we’ll break down how TLS certificates work, including Certificate Authorities (CAs), certificate validation, HTTPS, DNS, and advanced security mechanisms.

What is a TLS Certificate?

A TLS certificate is a digital certificate that verifies the identity of a website and encrypts communication between a client (browser) and server.

• Ensures data confidentiality (prevents eavesdropping).
• Prevents man-in-the-middle (MITM) attacks.
• Uses public-key cryptography for secure connections.

Example:

• When you visit https://www.amazon.com, your browser verifies that Amazon’s TLS certificate is valid before sending sensitive information.

End-to-End TLS Flow

1. User enters a URL in the browser (e.g., https://amazon.com).
2. DNS resolution happens — The browser queries DNS to get the IP address of amazon.com
3. Browser connects to the web server over HTTPS (TLS handshake begins)
4. Server sends its TLS certificate (issued by a trusted Certificate Authority).
5. Browser verifies the certificate by checking its authenticity (valid CA, expiration, domain match, etc.)
6. Session key is exchanged securely using asymmetric encryption.
7. A secure encrypted session is established — All further communication is encrypted.

Example:

• Without TLS, a hacker on the same WiFi network could intercept login credentials.
• With TLS, even if someone captures the data, it’s encrypted and unreadable.

Certificate Authority (CA) & Trust Chain

What is a Certificate Authority (CA)?

• A CA is a trusted organization that issues TLS certificates (e.g., DigiCert, Let’s Encrypt, GlobalSign).
• Browsers only trust websites with certificates issued by a valid CA.

Certificate Chain of Trust

TLS certificates are validated using a chain of trust:

1. Root CA Certificate (Top-level, highly trusted).
2. Intermediate CA Certificate (Issued by the root, used for day-to-day certificate signing).
3. End-Entity Certificate (Issued to a website like amazon.com)

When a browser visits amazon.com, it verifies the certificate chain back to the root CA.

Example:

• If you visit a fake banking website, it won’t have a certificate signed by a real CA, and the browser shows a security warning.

How Browsers Validate TLS Certificates

When you open a website, the browser performs several validation checks:

Is the certificate signed by a trusted CA?

• If the certificate is self-signed, the browser displays a security warning.

Has the certificate expired?

• Certificates usually expire in 1–2 years. An expired certificate breaks HTTPS connections.

Does the domain match?

• A certificate issued for google.com cannot be used for fake-google.com.

Has the certificate been revoked?

• Browsers check CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol)

How Does the TLS Handshake Work?

The TLS handshake is the process that establishes a secure encrypted connection between a client (browser) and a server. It ensures authentication, key exchange, and encryption setup before transmitting any actual data.

Steps of the TLS Handshake

Client Hello

• The client (browser) sends a “Hello” message to the server.
• Includes supported TLS versions, cipher suites, and a random number.

Server Hello

• The server responds with its TLS version, selected cipher suite, and another random number.
• Sends its TLS certificate (issued by a trusted CA).

Certificate Validation

• The client verifies the server’s certificate using CA trust.
• Ensures the certificate is valid, not expired, and issued for the correct domain.

Key Exchange (Symmetric Key Generation)

• Both client and server generate a shared encryption key using either:
• RSA (Older) — Encrypts the session key with the server’s public key.
• Diffie-Hellman / ECDH (Modern, used in TLS 1.2 and TLS 1.3) — Uses a secure mathematical function to generate a shared key.

Finished & Secure Session Established

• Both client and server confirm that encryption is successfully set up.
• All future communication is encrypted using the shared key.

Example of a TLS Handshake in Action

When you open https://www.gmail.com:

1. Your browser sends a “Client Hello” with supported encryption settings.
2. Gmail’s server responds with a “Server Hello” and its TLS certificate.
3. Your browser verifies Gmail’s certificate with its CA store.
4. A shared encryption key is generated securely.
5. All future emails and login details are encrypted between you and Gmail.

TLS 1.3 Handshake (Faster and More Secure)

• TLS 1.3 reduces handshake time (only 1 round-trip instead of 2).
• Removes RSA-based key exchange (uses Diffie-Hellman for Perfect Forward Secrecy).
• Improves speed and security for HTTPS websites, banking apps, and real-time messaging services.

TLS and DNSSEC (Preventing Spoofing Attacks)

Problem: DNS Spoofing Attacks

• Attackers can hijack DNS responses and redirect users to fake websites.
• Example: A user types bank.com, but an attacker redirects them to a fake bank website.

Solution: DNSSEC (DNS Security Extensions)

• DNSSEC cryptographically signs DNS responses, preventing tampering.
• Ensures that bank.com always resolves to the correct IP address.
• Works alongside TLS to secure internet traffic.

TLS at API Gateway & Load Balancers

Where is TLS Termination Done?

TLS encryption can be handled at different levels:

At the API Gateway (Best for Scalability)

• TLS is terminated at the API Gateway (e.g., AWS API Gateway, Kong, NGINX).
• Reduces load on backend microservices.

At the Load Balancer (NGINX, AWS ALB, Cloudflare)

• Load balancers decrypt TLS, inspect traffic, then re-encrypt before forwarding to the server.

End-to-End Encryption (Most Secure)

• TLS is not terminated at any intermediate point.
• Used in financial & healthcare systems for compliance.

Example:

• Netflix terminates TLS at AWS ELB (Elastic Load Balancer) before forwarding requests to microservices.

TLS in Cookies & Authentication

Securing Cookies with TLS

• Secure flag: Ensures cookies are sent only over HTTPS.
• HttpOnly flag: Prevents JavaScript from accessing cookies (prevents XSS attacks).
• SameSite flag: Protects against CSRF attacks.

Example:

• Without TLS, session cookies can be stolen by attackers.
• With TLS and Secure cookies, even if an attacker intercepts traffic, they cannot steal the session.

Advanced TLS Security Topics

8.1 Perfect Forward Secrecy (PFS)

• Uses ephemeral keys for each session.
• Even if a hacker steals a server’s private key, past encrypted sessions remain secure.

Example:

• Google and Facebook enforce PFS to protect against nation-state attacks.

TLS 1.3 (Latest TLS Version)

• Removes weak encryption algorithms like RSA key exchange.
• Reduces handshake time for faster HTTPS performance.
• Example: Major sites like Google and Cloudflare have migrated to TLS 1.3 for better security.

HSTS (HTTP Strict Transport Security)

• Forces browsers to always use HTTPS for a website.
• Prevents protocol downgrade attacks.

Example:

• Facebook and PayPal use HSTS to ensure all connections stay encrypted.

Conclusion

TLS is essential for secure communication in modern systems. By understanding how TLS certificates work, CA validation, DNSSEC, API Gateway TLS, and advanced security techniques, engineers can build scalable and secure distributed systems.

A well-implemented TLS strategy prevents MITM attacks, secures user sessions, and ensures compliance with security best practices.

TLS is the foundation of trust on the internet — securing billions of transactions every day across websites, APIs, and cloud systems.

I’ll be posting and stay consistent in both my learning followed by daily pushups. Thank you!

Follow my journey:
Medium: https://ankittk.medium.com/
Instagram: https://www.instagram.com/ankitengram/