180361797
submission
todd3091 writes:
The Snowden documents confirmed the NSA was running "harvest now, decrypt later" operations, recording encrypted traffic with the expectation of eventually stealing private keys. With RSA key exchange, one compromised key could decrypt years of recorded sessions. Perfect Forward Secrecy killed that attack vector. Each TLS connection generates ephemeral keys through Diffie-Hellman that get discarded after the handshake. The server's private key only authenticates identity, it never touches session encryption. TLS 1.3 made PFS mandatory in 2018, but plenty of systems still run TLS 1.2 with misconfigured ciphers. When Heartbleed hit, sites with PFS disclosed potential compromise of weeks of traffic. Sites without PFS had to disclose years.
180171339
submission
todd3091 writes:
An analysis of SSL certificate revocation reveals that the entire PKI revocation infrastructure is fundamentally broken, with browser vendors and CAs maintaining the system purely for compliance while knowing it doesn't work.
Testing shows that revoked.badssl.com, a certificate explicitly revoked for key compromise, loads successfully in Safari and Firefox while being blocked in Chrome. This happens because each browser implements its own proprietary revocation checking system with wildly different coverage. Chrome's CRLSet includes approximately 24,000 certificates out of over 2 million revoked certificates in the wild, effectively ignoring 98% of revocations.
The technical failures have been documented for years. CRLs grew to hundreds of megabytes, making them impossible to distribute efficiently. OCSP, designed to replace CRLs, suffers from median response times of 300ms and frequent timeouts, with Mozilla reporting nearly half their system failures stemming from OCSP issues. When OCSP fails, browsers default to "soft-fail" mode, allowing connections anyway. As Google's Adam Langley noted in 2012, "Soft-fail revocation checks are like a seat-belt that snaps when you crash."
OCSP stapling, meant to solve these problems, has less than 5% adoption. Even when implemented, stapled responses frequently expire without being refreshed, triggering soft-fail fallbacks.
The CA/Browser Forum's response has been to openly acknowledge defeat. In discussions about certificate lifetimes, members stated: "Given that revocation is fundamentally broken and we have no realistic path to fixing it, shorter certificate lifetimes are our only option." This led to the progressive reduction from 5+ year certificates in 2011 to the proposed 47-day certificates by 2029.
Every major browser has essentially rebuilt CRLs in proprietary, incompatible ways. Chrome uses CRLSets updated through Chrome's update mechanism. Firefox employs CRLite with Bloom filters. Apple aggregates CRLs at the OS level with an undocumented implementation. The result: whether a revoked certificate actually stops working depends entirely on which browser you use and when it last updated its proprietary list.
Full analysis: https://ancillary-proxy.atarimworker.io?url=https%3A%2F%2Fwww.certkit.io%2Fblog%2Fce...
