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, hash functions, digital signatures and digital certificates.

Syllabus Mapping (Cambridge International AS & A Level Computer Science 9618)

Key Concepts Overview (Cambridge Core Concepts)

• Data representation & structures – binary/hex representation of keys, certificates, and messages.
• Communication – use of TLS to protect data across networks.
• Security – confidentiality, integrity, authentication, non‑repudiation.
• Computational thinking – algorithmic steps of the TLS handshake.
• Programming paradigms – use of APIs (socket, SSL) and exception handling.
• System software – OS libraries (OpenSSL, SChannel) that implement TLS.

Glossary of Essential Terms

• Plaintext – original, readable data before encryption.
• Ciphertext – data after applying a cryptographic algorithm.
• Symmetric key – single secret key used for both encryption and decryption.
• Asymmetric (public‑key) pair – public key (shared) and private key (kept secret) used for key exchange and digital signatures.
• Hash function – one‑way algorithm that maps data of any size to a fixed‑size digest (e.g. SHA‑256).
• Digital signature – a hash encrypted with a private key; anyone can verify it with the matching public key.
• Certificate Authority (CA) – trusted third‑party that signs X.509 certificates.
• Forward secrecy – compromise of long‑term keys does not reveal past session keys.

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.
• Non‑repudiation (optional) – digital signatures can prove who sent a message.

Placement of TLS in the OSI / TCP‑IP Model

• Application layer – protocols such as HTTPS, FTPS, IMAPS use TLS to protect the payload.
• Transport layer – TLS sits above TCP; it encrypts the byte stream that TCP delivers.
• Internet layer – unchanged (IP routing).
• Link layer – unchanged (Ethernet, Wi‑Fi, etc.).

Operating‑System Support for TLS

• Socket API – OSes provide wrappers (e.g. SSLSocketFactory, SSL_socket) that handle the handshake automatically.
• Certificate store – a trusted root‑CA repository (Windows Certificate Store, Linux /etc/ssl/certs, macOS Keychain).
• Process isolation & permissions – prevent a compromised application from reading private keys stored on disk.
• System libraries – OpenSSL, GnuTLS, SChannel, SecureTransport implement the cryptographic primitives required by TLS.

Core Cryptographic Concepts Used by TLS

• Symmetric encryption – fast, used for bulk data after a secure channel is established (AES‑GCM, ChaCha20‑Poly1305).
• Asymmetric encryption (public‑key) – used to exchange symmetric keys securely (RSA, Diffie‑Hellman, ECDHE).
• Hash functions – provide message integrity and are used in the TLS PRF (SHA‑256, SHA‑384).
• Digital signatures – prove authenticity of certificates and of the handshake (RSA‑sign, ECDSA).

Illustrative RSA Example (Not required for the exam)

This small‑number example shows the mathematics behind the public‑key operations that occur when a client encrypts the pre‑master secret with the server’s RSA public key.

1. Choose two small primes: p = 61, q = 53.
2. Compute n = p·q = 3233 (modulus).
3. Compute φ(n) = (p‑1)(q‑1) = 3120.
4. Pick public exponent e = 17 (coprime to 3120).
5. Find private exponent d such that e·d ≡ 1 (mod φ(n)).
   Using the extended Euclidean algorithm, d = 2753.
6. Public key = (e, n) = (17, 3233); Private key = (d, n) = (2753, 3233).
7. Encrypt a message m = 65: c = m^e mod n = 65^17 mod 3233 = 2790.
8. Decrypt: m = c^d mod n = 2790^2753 mod 3233 = 65.

The SSL/TLS Handshake (TLS 1.2 – exam focus)

1. ClientHello
   • Supported TLS version (e.g. 1.2)
   • List of supported cipher suites
   • Random 32‑byte ClientRandom
   • Extensions (SNI, ALPN, supported groups, etc.)
2. ServerHello
   • Chosen TLS version
   • Chosen cipher suite
   • Random 32‑byte ServerRandom
   • Server’s X.509 certificate (contains RSA/ECDSA public key)
   • Optional ServerKeyExchange (for DH/ECDHE) and CertificateRequest (if client authentication is required)
3. Certificate Verification (client)
   • Validate the server certificate chain to a trusted root CA.
   • Check dates, hostname match, and revocation status (CRL/OCSP).
4. Key Exchange (depends on the selected cipher suite)
   • RSA key exchange: client creates a 48‑byte pre‑master secret, encrypts it with the server’s RSA public key, and sends the ciphertext.
   • Diffie‑Hellman / ECDHE: both sides exchange public parameters, compute a shared secret, and optionally sign the exchange with their private keys.
5. Generate Session Keys
   Both parties compute the master secret using the PRF:

   MasterSecret = PRF(PreMasterSecret, "master secret" || ClientRandom || ServerRandom)

   From the master secret they derive:
   • Client MAC key, Server MAC key
   • Client encryption key, Server encryption key
   • Client IV, Server IV (if required)
6. ChangeCipherSpec – a single‑byte message indicating that subsequent records will be protected with the newly derived keys.
7. Finished – each side sends a hash of all previous handshake messages, encrypted with the new keys, to confirm that the handshake was not tampered with.

Note on TLS 1.3

TLS 1.3 streamlines the handshake (often only one round‑trip) and removes static RSA key exchange. It is **outside the current syllabus** but useful for enrichment and for real‑world practice.

Cipher Suites – What They Contain

Digital Certificates and the PKI Trust Model

Certificates bind a public key to an entity’s identity and follow the X.509 standard.

• Certificate fields – Subject, Issuer, Validity period, Public key, Signature algorithm, Extensions.
• Chain of trust – Server certificate → Intermediate CA(s) → Root CA (pre‑installed in the client’s trust store).
• Revocation checking – Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP).

Security Considerations (What Students Must Remember)

• Use the latest version supported by the environment – TLS 1.3 is preferred, but TLS 1.2 is the minimum required for the exam.
• Prefer cipher suites that provide forward secrecy (ECDHE, DHE). If a long‑term private key is later compromised, past sessions remain safe.
• Validate certificates rigorously: check expiration, hostname, chain, and revocation status.
• Disable obsolete protocols (SSL 2.0/3.0, TLS 1.0/1.1) on both client and server.
• Configure only strong cipher suites – avoid CBC‑mode ciphers without encrypt‑then‑MAC and avoid SHA‑1.

Exam Essentials – What the AS/A‑Level Exam Requires

Design Scenario – AO2 (Apply Knowledge)

Situation: You are asked to design a secure instant‑messaging application that runs on desktop computers and mobile phones. The application must protect messages from eavesdropping and guarantee that the communicating parties are who they claim to be.

1. Choose a TLS version and justify your choice (e.g., TLS 1.3 for reduced latency and mandatory forward secrecy).
2. Select a cipher suite and explain why it satisfies confidentiality, integrity and forward‑secrecy requirements.
3. Describe how you would store and retrieve the server’s private key and the client’s trusted root certificates on the operating system.
4. Explain what would happen if the server’s certificate were revoked while a user already has an active session.

Mini‑Coding Exercise – AO3 (Implement & Test)

Write a short program (Java, Python or pseudocode) that:

1. Creates an SSL/TLS client socket that connects to example.com on port 443.
2. Performs the handshake, prints the negotiated TLS version and cipher suite.
3. Sends the string “Hello” over the encrypted channel and reads the server’s response.
4. Handles possible exceptions (e.g., SSLHandshakeException, certificate validation failure) and prints a user‑friendly error message.

Example (Python 3 using the ssl module):

import socket, ssl

hostname = 'example.com'
context = ssl.create_default_context()          # validates certificates
context.minimum_version = ssl.TLSVersion.TLSv1_3

try:
    with socket.create_connection((hostname, 443)) as sock:
        with context.wrap_socket(sock, server_hostname=hostname) as ssock:
            print('TLS version:', ssock.version())
            print('Cipher suite:', ssock.cipher())
            ssock.sendall(b'Hello')
            data = ssock.recv(1024)
            print('Received:', data.decode())
except ssl.SSLError as e:
    print('TLS error:', e)
except Exception as e:
    print('Connection failed:', e)

Students should run the program, note the output, then modify the context to force a weaker TLS version or an unsupported cipher suite to observe the resulting handshake failure.

Summary Checklist for Students

1. Identify the three security goals of SSL/TLS (confidentiality, integrity, authentication).
2. Explain why both symmetric and asymmetric encryption are needed in the handshake.
3. List the main messages exchanged during a TLS handshake and their purpose.
4. Describe the contents of an X.509 digital certificate and how a chain of trust is built.
5. State the importance of forward secrecy and name the key‑exchange methods that provide it.
6. Map TLS onto the OSI/TCP‑IP layers and name the OS services that support it.
7. Justify the choice of TLS version and cipher suite for a given application scenario.
8. Write and test a simple SSL client program, handling handshake errors gracefully.