COMP347 (Revision 10) | TrustOpen University
Upon completion of this expanded tutorial, students will be able to:
Application-layer security is paramount in modern networking, as applications handle sensitive user data and are exposed to sophisticated adversaries. This tutorial provides a rigorous, university‑level examination of the security mechanisms that protect application communications, with a primary focus on HTTPS and its underlying TLS protocol.
We begin with formal security models, including the Dolev‑Yao adversary and the CIA triad. We then dissect TLS 1.3, the current standard, detailing the handshake, key exchange, and record protocol. A comparison with TLS 1.2 highlights the security improvements (removal of weak ciphers, perfect forward secrecy by default). We explore the PKI ecosystem, including certificate validation, the role of CAs, and the emergence of Certificate Transparency to detect mis‑issuance. We then shift to web application security, covering the OWASP Top 10 vulnerabilities and their mitigations, including security headers like CSP, HSTS, and X‑Frame‑Options. Finally, we examine historical attacks (BEAST, POODLE, Heartbleed) and the lessons learned.
The Dolev‑Yao model formalises the adversary's capabilities: the attacker can intercept, replay, drop, and fabricate messages, but cannot break cryptographic primitives (i.e., the attacker cannot decrypt without the key). This model underpins the security proofs of TLS.
Messages explained:
TLS 1.3 uses the HKDF (HMAC‑based Extract‑and‑Expand) key derivation function based on the negotiated hash (e.g., SHA‑256). The steps:
Each stage produces separate keys for client‑to‑server and server‑to‑client traffic, ensuring forward secrecy (the handshake keys are independent of session keys).
The record protocol encapsulates application data and control messages. In TLS 1.3, it uses AEAD (Authenticated Encryption with Associated Data) modes like AES‑GCM or ChaCha20‑Poly1305. The record header includes the content type (always 23 for application data), the version (0x0304 for TLS 1.3), and the length. The payload is encrypted and authenticated in one pass.
| Feature | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake latency | 2 RTT (full) or 1 RTT (with session resumption) | 1 RTT (full) or 0‑RTT (with resumption) |
| Key exchange | RSA, DH, ECDH (static or ephemeral) | Ephemeral Diffie‑Hellman (ECDHE) only – mandatory PFS |
| Signature algorithms | RSA, DSA, ECDSA | RSA‑PSS, ECDSA, Ed25519 |
| Record encryption | MAC + CBC or AEAD | AEAD only (e.g., AES‑GCM) |
| Cipher suites | Many, including weak (RC4, 3DES) | Limited to AEAD, with no weak ciphers |
| Compression | Supported (but disabled) | Removed |
| Renegotiation | Supported | Removed |
| Session resumption | Session IDs or tickets | PSK with (EC)DHE or 0‑RTT |
0‑RTT allows a client to send application data in the first flight (ClientHello) if it has a PSK from a previous session. However, 0‑RTT is vulnerable to replay attacks; therefore, it is only safe for idempotent requests (e.g., GET). The server must implement replay detection (e.g., using a cache of tickets).
HTTPS is HTTP over TLS. It uses port 443 by default. The security benefits include confidentiality, integrity, and server authentication. Browsers enforce HTTPS for many features (geolocation, service workers) and mark HTTP sites as "Not Secure".
An X.509 certificate contains the subject (domain), public key, validity period, and the issuer (CA). The chain of trust: Root CA → Intermediate CA → Server certificate. Validation steps:
CT (RFC 6962) is a system where CAs must publicly log all issued certificates. Browsers require certificates to have a Signed Certificate Timestamp (SCT) from a trusted log. This prevents CAs from issuing certificates without public oversight, mitigating mis‑issuance and man‑in‑the‑middle attacks.
Let's Encrypt provides free, automated certificates using the ACME (Automated Certificate Management Environment) protocol. ACME uses challenges (HTTP‑01, DNS‑01, TLS‑ALPN‑01) to prove domain ownership, enabling auto‑renewal (certificates valid for 90 days).
| # | Category | Mitigation |
|---|---|---|
| A01 | Broken Access Control | Enforce least privilege, proper session management |
| A02 | Cryptographic Failures | Use TLS, strong cipher suites, secure key storage |
| A03 | Injection (SQL, XSS) | Parameterised queries, output encoding, CSP |
| A04 | Insecure Design | Secure by design, threat modelling |
| A05 | Security Misconfiguration | Hardening, minimal config, automated scanning |
| A06 | Vulnerable & Outdated Components | Regular updates, dependency scanning |
| A07 | Identification & Authentication Failures | Strong passwords, MFA, rate limiting |
| A08 | Software & Data Integrity Failures | Signed builds, integrity checks |
| A09 | Security Logging & Monitoring Failures | Comprehensive logging, incident response |
| A10 | Server‑Side Request Forgery (SSRF) | Validate and sanitise URLs, restrict outbound |
max‑age=31536000; includeSubDomains). Prevents SSL stripping.DENY or SAMEORIGIN).nosniff).strict‑origin‑when‑cross‑origin).| Attack | Description | Mitigation |
|---|---|---|
| BEAST (2011) | Exploits CBC mode in TLS 1.0; allows plaintext recovery | Use TLS 1.2+ with AEAD; disable CBC |
| POODLE (2014) | Padding oracle attack on SSLv3 | Disable SSLv3 |
| Heartbleed (2014) | Buffer over‑read in OpenSSL; leaks memory | Patch OpenSSL; use heartbleed‑free versions |
| DROWN (2016) | Cross‑protocol attack on RSA using SSLv2 | Disable SSLv2; use ephemeral key exchange |
| Logjam (2015) | Downgrade attack on Diffie‑Hellman with weak parameters | Use strong DHE groups (≥2048 bits); prefer ECDHE |
| Sweet32 (2016) | Birthday attack on 64‑bit block ciphers (3DES) | Disable 3DES; use AES |
Q1: In the Dolev‑Yao model, what is the attacker assumed to be capable of?
Intercepting, replaying, dropping, and fabricating messages, but cannot break cryptographic primitives.
Q2: What is the main purpose of the CertificateVerify message in TLS 1.3?
It contains a digital signature over the handshake transcript, proving the server's possession of the private key.
Q3: Which key exchange mechanism is mandatory in TLS 1.3?
Ephemeral Diffie‑Hellman (ECDHE) – providing perfect forward secrecy.
Q4: What is the primary security concern with 0‑RTT in TLS 1.3?
Replay attacks; the server must implement replay detection for non‑idempotent requests.
Q5: What is the role of Certificate Transparency?
It requires CAs to publicly log all issued certificates, allowing detection of fraudulent or mis‑issued certificates.
Q6: How does HSTS improve security?
It instructs the browser to only connect over HTTPS for a specified period, preventing SSL stripping and downgrade attacks.
Q7: What does the Content‑Security‑Policy (CSP) header do?
It restricts the sources from which resources (scripts, images, etc.) can be loaded, preventing XSS and data injection.
Q8: Which cryptographic attack exploited the CBC mode in TLS 1.0?
The BEAST attack.
Q9: What is the difference between CRL and OCSP for certificate revocation checking?
CRL is a periodically‑published list; OCSP is a real‑time query to a designated responder, providing more timely revocation information.
Q10: In TLS termination at a load balancer, where is the private key stored?
On the load balancer; the traffic to the origin server may be unencrypted, introducing a security risk if the network is not trusted.
Q11: What is the purpose of the `X‑Frame‑Options` header?
It prevents clickjacking by controlling whether the page can be embedded in frames (DENY, SAMEORIGIN).
Q12: Why was SSLv3 deprecated?
Due to the POODLE attack, which exploited a padding oracle vulnerability.
Exercise 1 – TLS Handshake Analysis
Describe the steps in a TLS 1.3 full handshake, including the cryptographic computations.
ClientHello (key_share) → ServerHello (key_share, certificate, certificate_verify) → Finished messages. The shared secret is derived via ECDHE; handshake transcript is hashed; HKDF derives traffic keys; Finished messages authenticate the handshake.
Exercise 2 – Certificate Validation
A browser receives a certificate with a valid signature but for a domain that doesn't match. What happens?
The browser shows a security warning. The connection may be encrypted, but the server identity is not verified, making it vulnerable to MITM attacks.
Exercise 3 – Security Header Configuration
Write the HTTP response headers for a website that wants to enforce HTTPS, prevent framing, and restrict scripts to its own domain.
Strict‑Transport‑Security: max‑age=31536000; includeSubDomains
X‑Frame‑Options: DENY
Content‑Security‑Policy: default‑src 'self'; script‑src 'self'
Exercise 4 – Attack Mitigation
Your server supports TLS 1.0 and 3DES. Which attacks are you vulnerable to and how would you fix them?
Vulnerable to BEAST (TLS 1.0), POODLE (if SSLv3 enabled), and Sweet32 (3DES). Fix: disable TLS 1.0 and 1.1, disable SSLv3, disable 3DES, and use only TLS 1.2/1.3 with AEAD ciphers (AES‑GCM, ChaCha20).
Exercise 5 – CSRF Protection
Explain how a CSRF token works and where it should be placed.
The server generates a random token per session (or per form) and embeds it in the HTML form or as a custom header. When the client submits the request, the token is sent back; the server verifies it. This ensures that the request originated from the legitimate site, not from a malicious third‑party.
Exercise 6 – Heartbleed Explanation
What was the Heartbleed bug and how was it exploited?
Heartbleed was a buffer over‑read vulnerability in OpenSSL's heartbeat extension. An attacker could send a heartbeat request with a length longer than the actual data, causing the server to return up to 64KB of memory contents, potentially leaking private keys, session data, and passwords. It was fixed by patching OpenSSL and re‑issuing certificates.
Homework 1 – TLS 1.3 Performance vs Security
Benchmark the performance of TLS 1.3 vs TLS 1.2 for a web server under load. Measure connection establishment time (full handshake and session resumption) and throughput. Analyse the impact of 0‑RTT on latency.
Use `openssl s_time` or `wrk` with TLS support.
Homework 2 – Certificate Transparency Analysis
Investigate a recently issued certificate using a CT log (e.g., crt.sh). Check the SCTs and the log inclusion proof. Write a report on how CT prevents MITM attacks.
Pick a common domain; inspect the certificate's SCTs and verify the signatures using CT tools.
Homework 3 – OWASP Top 10 Vulnerability Assessment
Perform a vulnerability assessment on a test web application (e.g., OWASP WebGoat) using OWASP ZAP. Identify at least five vulnerabilities and propose specific fixes for each.
Focus on authentication, injection, and misconfiguration issues.
Homework 4 – HSTS Preload Submission
Prepare a domain for HSTS preload submission. List the requirements (valid HTTPS, HSTS header with max‑age ≥ 1 year, includeSubDomains, preload). Document the process and test with the HSTS preload check.
Follow the hstspreload.org checklist.
Homework 5 – mTLS Implementation
Design a mutual TLS authentication scheme for a microservices architecture. Describe how certificates are issued, distributed, and renewed. Discuss the trade‑offs between mTLS and JWT for service‑to‑service authentication.
Include certificate lifecycle management using a PKI (e.g., Vault) and the use of SPIFFE identities.
This expanded tutorial has provided a comprehensive, university‑level examination of application‑layer security and HTTPS. Key takeaways:
Understanding these concepts is crucial for building secure networked applications and for staying ahead of evolving threats.