A birthday attack has nothing to do with birthdays or birthday-based passwords.
The name comes from the birthday paradox — a probability observation that only 23 people are needed in a room before there is a 50% chance that any two of them share a birthday. The key insight is "any two" rather than one specific target.
Applied to cryptography: finding any two inputs that produce the same hash is far easier than finding a specific input that produces a target hash, because you are searching for a match within a growing set of pairs. For a hash with N possible outputs, this takes approximately √N attempts — not N.
SSL stripping does not require, steal, or bypass the server's TLS private key.
SSL stripping works by preventing a TLS connection from being established in the first place. The attacker intercepts the server's 301 redirect to HTTPS before it reaches the victim's browser. The victim's browser never learns that HTTPS exists for this domain — it continues communicating over HTTP.
Because there is no TLS session between the victim and the attacker, no certificate is presented, no key is needed, and no decryption occurs. The victim's credentials arrive in plaintext because TLS was never negotiated — not because it was broken.
Labeling POODLE as only a downgrade attack misses the exploitation phase.
POODLE has two required phases that must both be present. Phase 1 (downgrade) forces the TLS negotiation to SSL 3.0 by injecting errors. Phase 2 (padding oracle) exploits a flaw in SSL 3.0's CBC mode padding to recover plaintext byte-by-byte. Neither phase alone constitutes a complete attack.
When the exam asks how to defend against POODLE, the correct answer addresses the downgrade: disable SSL 3.0 on the server. Without a fallback target, Phase 1 fails and Phase 2 is never reached. The defense targets the prerequisite.
MD5 is broken for collision resistance — but remains acceptable for non-security integrity verification.
MD5 must not be used in any context requiring collision resistance: digital signatures, certificate signing, authentication tokens, password hashing, or anything where an attacker could engineer two inputs with the same hash for fraudulent purposes.
However, MD5 remains acceptable for file download checksums where both parties are trusted and the goal is detecting accidental corruption, not adversarial substitution. This distinction matters because exam questions sometimes present "retire MD5 from all uses" as the correct answer — it is only correct in security-critical contexts.
Performance Task
You are a security consultant engaged to assess a mid-sized financial services firm's cryptographic posture. Your review produces the following three findings. For each finding, identify the attack it enables, classify it as an algorithm attack or an implementation attack, and recommend the specific remediation.
The firm's document management system generates digital signatures over contracts and compliance records using MD5 as the hash algorithm before encrypting with RSA-2048. The system has been in production since 2009 and handles legally binding documents.
Questions: What attack does this enable? Is this an algorithm or implementation attack? What is the specific remediation?
Attack enabled: Birthday attack / hash collision attack. An adversary who can engineer two documents with the same MD5 hash can have the firm sign a legitimate document and then substitute the fraudulent one — the RSA signature remains valid over the fraudulent document because both share the same MD5 hash.
Classification: Algorithm attack. The vulnerability is in MD5's mathematical structure — its collision resistance is broken. No matter how correctly MD5 is implemented, practical collisions can be generated. The RSA key strength (2048-bit) is irrelevant; the attack targets the hash, not the asymmetric cipher.
Remediation: Replace MD5 with SHA-256 in the signature algorithm (use SHA-256withRSA). SHA-256 provides 128-bit collision resistance — computationally infeasible with current technology. Existing MD5-signed documents should be re-signed with SHA-256 where legally required.
The firm's customer portal runs TLS 1.2 as its preferred protocol, but still advertises SSL 3.0, TLS 1.0, and TLS 1.1 in its server hello for backward compatibility with legacy browser clients. The portal handles customer authentication and account access.
Questions: What attacks does this enable? Is this an algorithm or implementation attack? What is the specific remediation?
Attacks enabled: POODLE (specifically targets SSL 3.0 fallback) and TLS downgrade attacks (any on-path attacker who can cause TLS 1.2/1.1/1.0 handshake failures can force fallback to SSL 3.0's CBC padding oracle). Once on SSL 3.0, the attacker can recover session cookies byte-by-byte using approximately 256 modified ciphertext requests per byte.
Classification: Implementation attack. TLS 1.2 is not broken — the vulnerability arises from the implementation allowing fallback to SSL 3.0. The deployment is vulnerable, not the algorithm. If SSL 3.0 were disabled, TLS 1.2 would remain secure.
Remediation: Disable SSL 3.0, TLS 1.0, and TLS 1.1 in the server configuration — support only TLS 1.2 (with strong cipher suites) and TLS 1.3. Configure TLS_FALLBACK_SCSV so any remaining fallback attempt causes the server to reject the downgraded handshake. Removing the legacy protocol support eliminates the fallback target; without a fallback destination, the downgrade has nowhere to land.
The customer portal serves all pages over HTTPS, and the server is configured to redirect HTTP requests to HTTPS with a 301 status code. There is no HSTS header present in any server responses. An analyst demonstrates that the portal's credentials can be captured on a shared Wi-Fi network by an on-path attacker.
Questions: What attack does this enable? Why is the 301 redirect insufficient? What specific controls would remediate the risk?
Attack enabled: SSL stripping. An on-path attacker (ARP poisoning on the shared Wi-Fi) intercepts the 301 redirect before it reaches the victim's browser. The victim's browser never receives the redirect, never learns HTTPS is available, and sends credentials over plaintext HTTP. The attacker holds an HTTPS session with the server. No browser warning appears because no TLS session was attempted.
Why the 301 redirect is insufficient: The 301 redirect is a server response — it travels across the network before reaching the browser, meaning an on-path attacker can intercept and drop it. The browser only knows to use HTTPS when it has already received the redirect. SSL stripping prevents that delivery.
Remediation: (1) Add the HSTS header to all HTTPS responses: Strict-Transport-Security: max-age=31536000; includeSubDomains. After the browser stores this policy, it will refuse to send any HTTP request to the domain — the initial HTTP request SSL stripping requires is never sent. (2) Submit the domain to the HSTS preload list so first-time visitors are also protected before they have ever visited the site. HSTS preloading ships the policy in the browser, eliminating the "first visit" attack window.