SSL/TLS: Handshakes, Encryption & Secure Web

TAKEAWAYS:

• SSL/TLS encrypts web traffic (e.g., eSewa payments) using asymmetric encryption for key exchange and symmetric encryption for speed.
• The TLS handshake authenticates the server (via certificates) and establishes a shared secret key in 3–4 rounds of message exchange.
• TLS Record Protocol splits data into records, compresses them, and encrypts each with AES or ChaCha20, adding HMAC for integrity.
• TLS sessions vs. connections: A session is a long-lived state (reused keys), while a connection is a single encrypted stream (e.g., one Daraz order).
• Certificate Authorities (CAs) like DigiCert or Sectigo issue digital certificates to verify server identity (e.g., https://daraz.np).
• Weak ciphers (e.g., RC4) or outdated TLS 1.0 can be exploited; modern TLS 1.3 removes legacy vulnerabilities.

1. Why SSL/TLS? The Problem It Solves

Before SSL/TLS, web traffic was sent in plaintext, vulnerable to:

• Eavesdropping: Attackers intercept passwords, credit cards, or messages (e.g., stealing eSewa transaction details).
• Man-in-the-middle (MITM): Fake servers impersonate esewa.com to steal login credentials.
• Data tampering: Hackers alter web pages or API responses (e.g., changing a Daraz order price).

SSL/TLS fixes this by:

1. Encrypting all data in transit (e.g., WhatsApp messages).
2. Authenticating the server (and optionally the client) using digital certificates.
3. Ensuring integrity so attackers can’t modify messages.

2. SSL vs. TLS: The Evolution

Modern browsers only support TLS 1.2+ (SSL is obsolete). Always use TLS 1.3 for best performance.

3. How TLS Works: The Handshake Protocol

The TLS handshake establishes a secure connection in 3–4 rounds of messages. Below is the TLS 1.3 handshake (simplified):

sequenceDiagram
    participant Client
    participant Server
    participant CA

    Client->>Server: ClientHello (cipher suites, TLS 1.3)
    Server->>Client: ServerHello + Certificate (signed by CA)
    Client->>CA: Verify certificate (public key)
    CA-->>Client: Valid (trust chain)
    Client->>Server: Encrypted ClientKeyShare (pre-master secret)
    Server->>Client: Encrypted ServerKeyShare + Finished
    Client->>Server: Finished (shared secret confirmed)

Key steps:

1. ClientHello: Client lists supported ciphers (e.g., AES-256-GCM) and TLS version.
2. ServerHello + Certificate: Server proves its identity via a digital certificate (issued by a CA like Sectigo).
3. Key Exchange: Client and server generate a pre-master secret (asymmetric encryption) and derive a symmetric session key (symmetric encryption for speed).
4. Finished: Both sides send a hash of all handshake messages to confirm no tampering.

Worked Example: Logging into eSewa

1. You open https://esewa.com → Browser sends ClientHello (TLS 1.3).
2. eSewa’s server responds with its DigiCert certificate (validated by your OS).
3. Your device and eSewa’s server negotiate AES-256-GCM and exchange keys.
4. All future data (password, transaction details) is encrypted with this key.

4. TLS Record Protocol: Encrypting Data

Once the handshake completes, TLS splits data into records and processes them:

graph TD
    A["Application Data"] -->|"Split"| B["Records (≤16KB)"]
    B --> C{"Compression?"}
    C -->|"Yes"| D["Compress"]
    C -->|"No"| D
    D --> E["Encrypt (AES-256-GCM)"]
    E --> F["Add HMAC (SHA-256)"]
    F --> G["Send over TCP"]

Fields in a TLS Record:

+---------------------+---------+---------+-----------+
| Content Type (1B)   | Version | Length  | Payload   |
+---------------------+---------+---------+-----------+
| HMAC (16B)          | Encrypted Data (variable) |
+---------------------+-------------------------------+

• Content Type: Data (22) or Alert (21).
• HMAC: Ensures no tampering (like a digital signature).
• Encryption: AES-GCM (authenticated encryption) or ChaCha20 (for mobile).

Why AES-GCM?

• Confidentiality: Encrypts data so only the client/server can read it.
• Integrity: HMAC detects if data is altered mid-transit (e.g., someone changes a WhatsApp message).

5. TLS Sessions vs. Connections

Why sessions matter:

• Performance: Avoid redoing the handshake for every request.
• Security: Session keys are rotated periodically (e.g., after 24 hours).

6. Digital Certificates: How Servers Prove Identity

A digital certificate binds a server’s public key to its domain (e.g., khalti.com). It contains:

• Subject: khalti.com
• Issuer: Sectigo (CA)
• Public Key: Used to verify the server’s signature.
• Validity Period: e.g., 1 year
• Extensions: Cipher suites allowed (e.g., TLS_AES_256_GCM_SHA384).

How it works:

1. Client checks the certificate’s trust chain (e.g., Sectigo → Root CA → Your OS).
2. If valid, the client extracts the server’s public key to verify its ServerKeyShare in the handshake.

Real-world example: When you visit https://khalti.com, your browser checks the certificate issued by Sectigo to ensure you’re talking to the real Khalti, not a fake site.

7. Security Threats and Mitigations

8. Real-World Applications

In the Real World

1. eSewa/Khalti Payments

   • Idea: TLS 1.3 encrypts transaction data (e.g., card numbers) during checkout.
   • How: The handshake authenticates esewa.com via a Sectigo certificate, then encrypts all payment details.

2. WhatsApp End-to-End Encryption

   • Idea: TLS secures the initial connection; Signal Protocol (built on TLS) encrypts messages.
   • How: WhatsApp uses TLS 1.2 for the handshake, then switches to Signal’s double ratchet algorithm for chats.

3. YouTube HTTPS

   • Idea: TLS protects video streams from ISPs or attackers.
   • How: YouTube enforces TLS 1.2+ and uses OCSP stapling to validate certificates quickly.

9. Exam Tip: How This Unit Is Tested

1. Definitions:

   • Know the difference between TLS session (long-lived) and connection (short-lived).
   • Explain HMAC (message integrity) vs. encryption (confidentiality).

2. Handshake Steps:

   • Draw the TLS 1.3 handshake (4 messages) and label:
     • ClientHello, ServerHello, Certificate, Finished.
   • Mention key exchange (ECDHE) and session resumption (SessionTickets).

3. Record Protocol:

   • Describe how data is split, compressed, encrypted, and HMAC’d.
   • Compare AES-GCM (authenticated encryption) vs. ChaCha20.

4. Certificates:

   • Explain CA hierarchy (root → intermediate → server).
   • Why OCSP stapling is better than checking CRLs.

5. Threats:

   • List MITM, downgrade, and side-channel attacks with fixes.
   • Know why TLS 1.3 removes old ciphers like RC4.

6. Worked Example:

   • Trace a TLS handshake for a Daraz order (steps 1–4 above).
   • Calculate session key derivation (e.g., PreMasterSecret + ClientRandom + ServerRandom).

Final Tip: Always assume the exam will ask for:

• A handshake diagram (use Mermaid).
• A comparison table (e.g., SSL vs. TLS).
• A real-world scenario (e.g., Khalti’s TLS usage).
• Security weaknesses (e.g., "Why is TLS 1.0 broken?").

sequenceDiagram
    participant C as Client
    participant S as Server
    participant CA as CA

    C->>S: ClientHello (TLS 1.3, cipher suites)
    S->>C: ServerHello + Certificate (Sectigo)
    C->>CA: Verify certificate (trust chain)
    CA-->>C: Valid
    C->>S: Encrypted ClientKeyShare (ECDHE)
    S->>C: Encrypted ServerKeyShare + Finished
    C->>S: Finished (shared secret confirmed)