Watching #heartbleed (aka CVE-2014-0160) fly by in my twitter stream this week, I keep wishing we could all just pause time for a couple of weeks and properly reflect on all the angles here.
Some of the things I'd love to have more time to dig into:
- Obviously, the bug itself and its fix
- Why countermeasures in the kernel, libc or the compiler didn't prevent this, or how static analysis tools didn't catch it. (Update: see here and here)
- The protocol design - some wonder why a seemingly application-level feature is included in such a critical security protocol and why the feature is available before authentication has completed. Interesting to note that one of the stated purposes of the feature is PMTU discovery for DTLS yet it's enabled for plain TLS too
- That it's not only servers which are vulnerable - clients equally vulnerable
- The fact that attacks can't be detected because there is no logging of this failure condition
- The health of the OpenSSL project, talk of its developers being irresponsible when it comes to their development practice
- How the bug was introduced, how much code review or testing was involved. (Update: comments from the original author of the code)
- The realization that few in our industry are actively investing in this project which so many place so much trust in
- The question of whether OpenSSL is the library everyone should be relying on, whether it should be e.g. NSS or GnuTLS
- How something like OpenSSL can be a critical part of a web service's architecture even where e.g. the service is implemented with technologies like .NET
- The question of whether we're putting all our eggs in one basket if an SSL vulnerability can have such far reaching implications
- Just how much was exposed by the vulnerability - e.g. private keys, usernames and passwords, other sensitive data - and how much data could have been compromised by a determined, well-resourced attacker in possession of this knowledge before it was patched
- The efficacy of certificate revocation measures in protecting users from potentially compromised certificates
- How Perfect Forward Security is an important mitigation measure for vulnerabilities like this
- The claim by one site that they could detect attacks in their logs, that there was someone exploiting the vulnerability two weeks before it was disclosed publicly. (Thierry Carrez points out the update to this post which says "other tools [..] can produce the same pattern in the SeaCat server log")
- How our perception of a vulnerability like this has changed now that we know just how aggressive intelligence agencies (the NSA and others) are in their approach to population surveillance and monitoring. This FOSDEM talk is rather prescient in describing OpenSSL as the "crown jewels" for the NSA. (Update: claims that the NSA knew of the bug soon after its introduction and exploited it)
- The approach that was taken to disclosing the vulnerability, how responsible a disclosure process it was and the pros/cons of delaying disclosure further. Apparently CloudFlare was disclosed before the public disclosure, whereas vendors like Red Hat weren't. (Update: more details on the disclosure timeline from Kurt Seifried) (Another update: OpenSSL's official view of the timeline) (Yet another update: interview with Codenomicon's David Chartier)
- How effective entities like Linux distros were in helping getting the vulnerability quickly patched in the wild (see e.g. that Stripe went and built their own patched package rather than wait for an Ubuntu package)
- How much more difficult patching this was due to applications bundling OpenSSL and how much worse it could have been if the practice of bundling was more widespread
- The impact that the impressive marketing - i.e. a cool name vs simply a CVE number, a logo, clear technical writing which speaks to the business impact, etc. - had on the speed with which the patch was deployed