Show awareness of the Secure Socket Layer (SSL)/Transport Layer Security (TLS)

17.1 Encryption, Encryption Protocols and Digital Certificates

Learning Objective

Show awareness of the Secure Socket Layer (SSL) / Transport Layer Security (TLS) protocol, its role in securing data transmission, and the supporting concepts of encryption and digital certificates.

1. Why SSL/TLS is Needed

• Confidentiality – data must be unreadable to eavesdroppers.
• Integrity – ensure data is not altered in transit.
• Authentication – verify the identity of the communicating parties.

2. Core Cryptographic Concepts Used by SSL/TLS

• Symmetric encryption – fast, used for bulk data after a secure channel is established.
• Asymmetric encryption (public‑key) – used to exchange symmetric keys securely.
• Hash functions – provide message integrity (e.g., SHA‑256).
• Digital signatures – prove authenticity of certificates.

3. The SSL/TLS Handshake – Step by Step

1. ClientHello – client proposes TLS version, cipher suites, and a random value ClientRandom.
2. ServerHello – server selects protocol version, cipher suite, sends its own random value ServerRandom, and its digital certificate.
3. Certificate \cdot erification – client validates the server’s X.509 certificate against trusted root CAs.
4. Key Exchange – depending on the cipher suite:

   • RSA: client encrypts a pre‑master secret with the server’s public key and sends it.
   • Diffie‑Hellman (DHE/ECDHE): both parties exchange public parameters and compute a shared secret.

5. Generate Session Keys – both sides compute the master secret and derive symmetric keys:

   \$\text{MasterSecret} = \text{PRF}(\text{PreMasterSecret},\; \text{ClientRandom} \parallel \text{ServerRandom})\$

6. Finished Messages – each side sends a hash of all handshake messages encrypted with the newly derived keys to confirm integrity.

4. Cipher Suites – What They Contain

5. Digital Certificates and the PKI Trust Model

Certificates bind a public key to an entity’s identity. They are issued by Certificate Authorities (CAs) and follow the X.509 standard.

• Certificate fields – Subject, Issuer, Validity period, Public Key, Signature.
• Chain of trust – Server certificate → Intermediate CA(s) → Root CA (trusted by the client).
• Revocation checking – CRL (Certificate Revocation List) or OCSP (Online Certificate Status Protocol).

6. Example of RSA Key Exchange in TLS

When RSA is used, the client generates a 48‑byte pre‑master secret:

\$\text{PreMasterSecret} = \text{Random}(48)\$

The client encrypts it with the server’s RSA public key e, n:

\$\text{Encrypted} = \text{PreMasterSecret}^e \bmod n\$

The server decrypts with its private key d, n to recover the same pre‑master secret, after which both sides derive the master secret and session keys as shown earlier.

7. Security Considerations

• Always use the latest TLS version (TLS 1.3) – it removes obsolete algorithms and reduces handshake round‑trips.
• Prefer cipher suites with forward secrecy (e.g., ECDHE) to protect past sessions if long‑term keys are compromised.
• Validate certificates strictly – check expiration, hostname matching, and revocation status.
• Disable insecure protocol versions (SSL 2.0/3.0, TLS 1.0/1.1) on servers and clients.

8. Summary Checklist for Students

1. Identify the three security goals of SSL/TLS.
2. Explain the role of symmetric and asymmetric encryption in the handshake.
3. List the main messages exchanged during a TLS handshake.
4. Describe what a digital certificate contains and how trust is established.
5. State why forward secrecy is important and which key‑exchange methods provide it.