Example 1 · MD5 Hash Collision — What It Actually Looks Like
A hash collision is easier to understand with a concrete example. The following illustrates the fundamental problem with MD5.
Expected behavior:
A cryptographic hash function should produce a completely different output for any two different inputs — even inputs that differ by a single bit. This property is called avalanche effect:
Input: "hello"
MD5: 5d41402abc4b2a76b9719d911017c592
Input: "hellp" (one character changed)
MD5: 8d5b6f77028d10c02aaafdb78a53f72c
These are completely different hashes for a single character change — exactly as expected.
The collision problem:
Researchers in 2004 demonstrated that MD5 can be made to produce the same hash for two inputs that are meaningfully different — not just a one-character variation, but inputs with different structure and purpose. The two inputs shown below are different binary files. The content that differs is indicated by their structure, but the MD5 hash is identical for both:
File A (legitimate certificate request for domain.com)
MD5: a3f8d29c1b7e4062f5a8b3c9d1e2f047
File B (fraudulent CA certificate with signing authority for ALL domains)
MD5: a3f8d29c1b7e4062f5a8b3c9d1e2f047
Same hash. Different content. Different purpose. This is the attack surface the December 2008 researchers exploited.
Why this breaks digital signatures:
A CA signs a certificate by computing hash(File A) and encrypting it with their private key. Verification: decrypt the signature → get hash(File A) → compute hash(presented file) → compare. If an attacker can engineer File B to have the same hash as File A, the CA's signature validates against File B — even though the CA only ever saw and approved File A. The CA's private key was never compromised. The CA never signed the fraudulent certificate. The hash function's collision allowed the forgery.
The defense in numbers:
SHA-256 produces a 256-bit hash. The birthday attack requires approximately 2128 operations to find a collision — far beyond current or near-future computing capability. MD5's 128-bit output gives only about 264 birthday-bound resistance, and its structural weaknesses reduce this further. The lesson: output size matters, but algorithm quality matters equally.
Example 2 · SSL Stripping — A Coffee Shop Credential Capture
A practical scenario illustrating how SSL stripping unfolds from the attacker's and victim's perspectives simultaneously.
The setup:
An attacker at a coffee shop runs an ARP poisoning attack on the local Wi-Fi network, positioning themselves between all connected clients and the router. A victim connects their laptop to the coffee shop Wi-Fi and opens their browser to check their work email at webmail.company.com.
What the victim sees:
Browser address bar: http://webmail.company.com/login
Page: Normal login form — username and password fields
Padlock icon: Absent (HTTP connection)
Connection: Appears to work normally
The victim types their username and password and clicks Login. The page responds with their inbox. Everything looks fine.
What actually happened — the attacker's view:
[Captured] Victim → Attacker: GET http://webmail.company.com/ (HTTP)
[Forwarded] Attacker → Server: GET http://webmail.company.com/ (HTTP)
[Intercepted] Server → Attacker: 301 Moved → https://webmail.company.com/ (HSTS redirect)
[Not forwarded] Attacker strips the redirect
[Established] Attacker → Server: HTTPS session (attacker's HTTPS)
[Sent] Attacker → Victim: 200 OK (over HTTP — victim stays on HTTP)
[Captured] Victim → Attacker: POST /login user=sarah&pass=Tr0ub4dor (plaintext HTTP)
[Forwarded] Attacker → Server: POST /login (over HTTPS, using Sarah's credentials)
[Captured] Attacker logs: sarah / Tr0ub4dor
Why the victim had no warning:
The webmail server had HTTPS configured. It was trying to redirect the victim to HTTPS. But the redirect never reached the victim's browser — the attacker intercepted it. The victim's browser saw only HTTP responses and had no reason to display a warning. There was no certificate error because no certificate was presented over the victim's connection — they were on plain HTTP.
The HSTS fix:
If webmail.company.com had HSTS configured and the victim had previously visited the site, the browser would have stored the HSTS policy: "Always use HTTPS for this domain." The victim's browser would have silently upgraded the initial request to HTTPS before sending it — the HTTP request that SSL stripping requires would never have been sent. The attacker would have seen an encrypted HTTPS request they could not strip.
Example 3 · POODLE — Forcing the Fallback
How POODLE works as a two-phase attack: downgrade first, exploit second.
The target environment:
A bank's web server in 2014 supports TLS 1.2 (preferred) but also has SSL 3.0 enabled as a fallback for customers still using older browsers. A victim visits the bank's site over a Wi-Fi network where an attacker has positioned themselves on-path.
Phase 1 — The downgrade:
The victim's browser initiates a TLS 1.2 handshake with the bank's server. The attacker injects errors into the handshake, causing the connection to fail. The browser retries with TLS 1.1 — the attacker injects errors again. The browser retries with TLS 1.0 — errors again. Finally, the browser offers SSL 3.0 as a last resort. The server, which has SSL 3.0 enabled for backward compatibility, accepts. A connection is established.
Neither the victim nor the server intended to use SSL 3.0. Both would have preferred TLS 1.2. The attacker's interference forced the fallback.
Phase 2 — The padding oracle:
Now running over SSL 3.0 CBC mode encryption, the attacker begins sending the server modified versions of encrypted blocks — specifically, blocks that contain the session cookie. By observing whether the server returns a padding error or processes the request normally, the attacker gains one bit of information per request about the plaintext content. With enough requests (roughly 256 per byte of plaintext), the attacker reconstructs the session cookie byte by byte.
Why modern systems are immune:
- Modern browsers remove SSL 3.0 from their supported protocol list — there is no fallback target for the downgrade to reach
- Servers with SSL 3.0 disabled refuse any negotiation at that level — connection fails completely rather than succeeding on a weak protocol
- TLS_FALLBACK_SCSV signals to the server that this is a fallback attempt; if the server supports higher versions, it rejects the downgraded handshake
Key exam distinction:
POODLE is classified as both a downgrade attack and a padding oracle attack. The downgrade is the prerequisite; the padding oracle is the exploitation. Without the downgrade to SSL 3.0, the padding oracle technique cannot be applied because modern TLS does not have SSL 3.0's padding vulnerabilities. Both halves must be understood to correctly classify the attack and choose defenses.
Exam Scenario 1 · Attack Classification
Scenario: A security analyst reviews the following findings from a recent penetration test: (A) the application's document signing system uses MD5 to hash documents before applying a digital signature; (B) a user on an unsecured Wi-Fi network connected to a corporate portal via HTTP and had their login credentials captured by an on-path attacker who prevented the HTTPS redirect from reaching the browser; (C) a TLS vulnerability was found where the web server still advertises SSL 3.0 as a supported protocol, allowing an attacker to force a fallback to that version and exploit its CBC padding weakness.
Question: Classify each finding and identify the primary defense for each.
Answer:
(A) Birthday attack / hash collision risk. MD5 has demonstrated practical collision vulnerabilities. An attacker could engineer two different documents that produce the same MD5 hash, then have a legitimate document signed while substituting the fraudulent one — the signature would validate on the fraudulent document. Defense: replace MD5 with SHA-256 for all document signing.
(B) SSL stripping (a downgrade attack). The attacker intercepted the server's HTTP-to-HTTPS redirect and maintained an unencrypted HTTP channel with the victim. Defense: implement HSTS on the corporate portal so the browser refuses to send any HTTP requests to the domain.
(C) POODLE / TLS downgrade attack. SSL 3.0 support on the server enables an on-path attacker to force a version downgrade and exploit SSL 3.0's CBC padding oracle to extract session content. Defense: disable SSL 3.0 (and TLS 1.0/1.1) on the server; configure TLS_FALLBACK_SCSV.
Exam Scenario 2 · Why the Defense Works
Scenario: A security architect is hardening the company's public-facing web application. They implement: (1) all HTTP requests are redirected to HTTPS with a 301 response; (2) the HTTPS response includes the header Strict-Transport-Security: max-age=31536000; (3) the server configuration removes SSL 3.0, TLS 1.0, and TLS 1.1 from supported protocol versions; (4) all certificates are issued with SHA-256 signatures. Identify which attack each control specifically addresses.
Answer:
(1) HTTP-to-HTTPS 301 redirect alone: Insufficient against SSL stripping — the attacker intercepts the 301 before it reaches the browser. The redirect must be combined with HSTS to be effective.
(2) HSTS header: Addresses SSL stripping. Once the browser has seen the HSTS header and stored the policy, it will refuse to send any HTTP request to this domain — the initial HTTP request that SSL stripping requires will never be sent. The attacker has nothing to intercept.
(3) Disabling SSL 3.0, TLS 1.0, TLS 1.1: Addresses POODLE and all TLS downgrade attacks targeting these protocols. If the server refuses to negotiate these versions, there is no fallback target for the downgrade to land on. TLS 1.2 or 1.3 will be used, and neither has the CBC padding oracle weakness exploited by POODLE.
(4) SHA-256 certificate signatures: Addresses birthday attacks / hash collision attacks against the certificate validation chain. SHA-256 provides 128-bit collision resistance — computationally infeasible to forge with current technology. This prevents the 2008-style MD5 CA certificate forgery from being applicable to this server's certificate.