Understanding TLS Concepts

Core Security Concepts

• Encryption: Scrambles or encodes the data.
• Authentication: Verifies the access must be given to authenticated users only.
• Integrity: Ensures data is not altered during transmission.

---

Encryption Overview

Encryption protects data transmitted between a client and server by changing it into random characters.

Steps Involved (Simplified)

1. TLS Handshake:
   • During the TCP 3-way handshake, before client and server do the TLS handshake, both parties decide which encryption to use, which algorithm to use, and how to construct a shared secret.
   • Server also sends its certificate so the client can verify if the public key belongs to the server.
2. Key Pair Generation:
   • Each party generates its own key pair.
   • Private key: Not shared.
   • Public key: Shared publicly.
3. Asymmetric Encryption:
   • Client has (CPriv, CPub), Server has (SPriv, SPub).
   • Private keys are not exchanged, but public keys are.
   • After this, both client and server compute a shared secret.
   • Mechanisms like Diffie-Hellman (DH) or Elliptic Curve DH (ECDH) are used.
   • Client side: SharedSecret = f(CPriv, SPub).
   • Server side: SharedSecret = f(SPriv, CPub).
   • Mathematically, f() is designed so both sides compute the exact same shared secret.
   • The basic aim is to prevent any 3rd party interference in communication.
   • Note: Asymmetric encryption is complex and requires high CPU usage. It's used in the handshake only; later, symmetric encryption is used for transferring data.
4. Symmetric Encryption:
   • The SharedSecret is not directly used.
   • A Key Derivation Function (KDF), like HKDF or PBKDF2, is used to derive the Symmetric Key from the SharedSecret.
   • Symmetric_Key = KDF(SharedSecret, salt, context-info).
   • The derived key is a symmetric encryption key. Algorithms like AES-128-GCM or ChaCha20-Poly1305 use this key.
5. Key Derivation (General Concept):
   • Think of the SharedSecret like a seed.
   • We can grow different things (keys) according to our need.
   • Encryption Key: Used to encrypt/decrypt data.
   • MAC/Integrity Key: Used to check if data is not altered. TLS uses HMAC (Hashed Message Authentication Code).
   • IV/Nonces: Randomness for each message. An IV is an Initialization Vector.
6. Rekeying / Renegotiation:
   • If a single key is used for a very long period, attackers can exploit vulnerabilities by collecting many ciphertexts.
   • Solutions today include:
     1. Periodically renewing the SharedSecret basis.
     2. Performing a full handshake again.

---

Authentication Process

Basically, encryption is not the only solution for security. How does a client know that 'yes, this is the server'?. Another problem: how will the client know a verified correct server has shared its public key, not any other fake 3rd party?.

Solution: Certificates & Certificate Authority (CA)

1. Server has a key pair (SPub, SPriv). Server provides its SPub to the client.
2. Server attaches a certificate along with its public key.
3. Certificate Contents: Server's name/domain, Public key, Expiry date, Issuer Signature.
4. When a client sends a message to the server, the server basically signs the message with its SPriv before sending it to the client.
5. Client uses the SPub (obtained from the certificate) to verify the signature. If valid, the client knows it is the same server whose SPriv it is associated with.
6. The CA is a trusted 3rd party organization that issues digital certificates.
7. A website certificate chain typically has 3 levels:
   • 1. Service certificate (issued to the website).
   • 2. Intermediate certificate (CA's certificate).
   • 3. Root certificate (Top level trusted CA).
8. The Root CA certificate is self-signed.
9. Note: When browsing the internet (https://), the browser uses the CA to confirm the website is genuine.

Verification Process:

1. Client (browser) connects to any resource (website).
2. Server sends its certificate chain (Service -> Intermediate -> Root).
3. Client (browser/OS) checks its system's trusted store.
4. If the root is not in the trusted list, the chain is verified in reverse order (Root CA -> Intermediate CA -> Service Certificate).
5. If everything is valid, the browser confirms that the server is authentic.

Common Mistake: Expired Certificates

• If a server's certificate expires, the client won't trust it.
• The connection will fail.
• Automation tools are used to auto-renew before expiry for this purpose.

---

Integrity

• The main goal is that data must be secure and unaltered.
• Only encryption and authentication cannot check this.
• Example: Client sends Amount $1000 to Server. An attacker can't read the data (due to encryption), but they can alter random bits of the data.
• For this purpose, we need an extra step of verification (like HMAC).

---

Special Section on KDF (Key Derivation Function)

• SharedSecret is constructed during the TLS handshake.
• Now, the SharedSecret is passed through a Pseudo-Random Function (PRF) and processed.
• The MasterSecret is derived.
• This MasterSecret is the source for symmetric key generation.
• During TLS 1.0/1.1/1.2, a custom HMAC-based PRF is used.
• But TLS 1.3 onwards, HKDF (HMAC-based Key Derivation Function) is used for deriving the master-secret.

Simplified Process in TLS 1.3

• traffic-secret = HKDF-Extract(SharedSecret, ...)
• key = HKDF-Expand(traffic-secret, "key", ...)
• iv = HKDF-Expand(traffic-secret, "iv", ...)
• In TLS 1.3, the master-secret is not actually used directly; it's a layered secret.
• master-secret is approximately equivalent to the traffic-secret.