Heartbleed

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:

12 thoughts on “Heartbleed”

  1. > * The health of the OpenSSL project, talk of its developers being irresponsible when it
    > comes to their development practice
    > * 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
    > * The question of whether we’re putting all our eggs in one basket if an SSL
    > vulnerability can have such far reaching implications

    I feel these 4 are all different facets of the same point. The last one in particular though poses quite a difficult conundrum. Conventional wisdom is that having all your eggs in one basket is a bad thing because of the implications when something goes wrong. With cryptography though, I’m not sure that conventional wisdom works out well in practice. It is pretty clear that writing secure crypto libraries is a very hard job, for which the community/industry has a pretty limited pool of skilled & interested developers. If we were to spread our eggs by having 10 widely used crypto libraries instead of just the 3 main open sources impls (OpenSSL, NSS, GNUTLS) we’d be spreading that limited pool of dev resources even thinner. The end result would likely be that the libraries would be lower quality overall, thus actually increasing our overall security risks. People auditing crypto libraries would also have much more work todo if there were more libraries to audit. Application developers would have harder decisions to make – do they pick just one, or do they try to support a whole bunch of different libraries which increases the chance they’ll screw up their integration causing more security flaws. Is 3 the right number of eggs to have in our basket – IMHO it probably is for now, given the other problems inherent in diversifying further.

    I think the second point is the key one to think about here. IMHO too many companies are shipping & relying on our three main open source TLS libraries without contributing enough resources to their development & testing – its a collective failure of investment since it isn’t a “sexy” headline grabbing project to throw resources at like, say, OpenStack. Count how many developers companies have thrown at OpenStack in the past 2 years and then count the same for the GNUTLS/OpenSSL/NSS projects…

    Serious as this, and the other 2 TLS impl vulnerabilities this year, are though, we have to bear in mind that (the NSA aside) TLS/SSL has actually done a remarkable job at protecting internet traffic over the past 10-15 years. It seems that the internet is going through a period of attitude readjustment due to the Snowden revelations, with greater interest/activity in auditing security sensitive code, including our TLS impls, leading to a significant uptick in vulnerabilities identified. Hopefully this will lead to better development and testing practices, and a greater long term investment in security work from everyone involved & relying on them.

  2. Re static analysis, I see that openssl is registered here and the last run was a year ago, though results aren’t publicly available: https://scan.coverity.com/projects/294?tab=Overview

    Though I’d be surprised if static checking pointed any issue here, and checking a coverity scan I do have for d1_both.c doesn’t show anything.

    I guess the security agencies would have more focused tools. clients searching for server stack/heap tagged values would be a cracking 101 tool I expect.

  3. This is a great list, Mark. I’d also add:

    * The prevalence of openssl in embedded devices that aren’t going to get updated, but will appear secure from here on out.

Comments are closed.

Leave a Reply

Your email address will not be published. Required fields are marked *