Robert Graham of Errata Security recently wrote in a blog post that over 300,000 hosts are still vulnerable to the OpenSSL heartbleed bug and posited that people had stopped even trying to patch.

While disconcerting, I imagine that a significant portion of the ~300k reported are embedded systems and that sysadmins are likely aware of the issue but effectively have their hands tied until their vendors submit a patch. Given that many consumer devices like DSL CPE’s are seldom updated, and many ISPs make the mistake of leaving remote administration open without even applying basic security hygeine practices like IP filtering to only their internal networks, I assume that these problems won’t be solved any time soon. Heck, there are still routers affected by the d-link hardcoded administrative password vulnerability that remain accessible.



Amusingly, Apple appeared to have neglected to renew a certificate used for one of their software update servers, resulting in users being declined the ability to perform updates or install software from the Mac Store. The issue, which presumably began on May 24, 2014 (the original certificate’s expiration date) and was corrected soon after, but not before many took to the Internet to vent their frustration that one of the world’s biggest software companies could neglect to update their SSL certificates.


Cloudflare Writes On The Deprecation Of RC4

The move away from RC4 to AES is a sensible pre-emptive action being taken by those in the industry. Cloudflare recently wrote a blog post detailing their rationale for removing RC4 as a supported cipher for modern browsers using TLS 1.1 or greater. I re-iterate that RC4 has not been demonstrably broken but it would appear only a matter of time.

SSL Implementations, Code Quality and Common Sense


The far reaching consequences of the Heartbleed vulnerability have been discussed at length in a thread on Bruce Schneier’s blog. In response to a comment on the code quality I wrote the following:

“I nodded in agreement so hard [at another user’s comment on OpenSSL code quality] I might have to see a chiropractor.

OpenSSL’s src is a mess. If cyaSSL can mirror its basic functionality and do such a thing with code that is both legible and importantly it is advertized as 20 times smaller than OpenSSL. Of course it is targeted towards the embedded market but I would rather audit a significantly smaller codebase that a lay sysadmin can likely understand than try and analyze the Pandora’s box that is OpenSSL’s source. It really is a disgrace.

Feature creep is a terrible thing. Security critical libraries should focus on their task. At least move redundant or niche usage extensions and other foolery out of the core and disable them unless uncommented in the Makefile at compile time.”

Now, of course I wouldn’t see a chiropractor. All scientific evidence points to the practice as ineffective folk medicine. But I digress. The point of my post is to highlight the (perhaps obvious) fact that as a library grows and more lines of code are written, so too does the potential for a potentially catastrophic bug to occur.

Good programming in the true style of our BSDite forefathers focuses on a few key laws, and these hold true regardless of what you are coding and what language you happen to be coding in. Essentially these boil down to the KISS principle – write good, well commented code and code with grace. What can be done in five lines may be done in one, but only if this does not negatively affect the readability (and thus the ability of others to audit) of your code. Extending upon this, be sure to separate out any unnecessary fluff from your core code. A feature that is used by perhaps one percent of your users should not be compiled in by default, especially in the case of a security critical library. The final tip is to sanity check everything and always distrust information pulled from external sources (i.e. the foreign host).

Of course all of the above is common sense. Unfortunately this has been lacking in many open source projects, and has been an issue ever since Stallman wanted EMACS to be everything including the kitchen sink.


CloudFlare recently claimed that although serious the Heartbleed bug could not be used to successfully hoover up the site’s private key. They have put up an intentionally vulnerable site, challenging the security community to prove that key theft via this bug is possible.

UPDATE: within a few hours two people had independently stolen the private key. So much for their contention that the threat posed by Heartbleed was overrated.

Developer Responsible For Heartbleed Speaks


German OpenSSL developer Robin Seggelmann spoke openly and was quoted by several newspapers about his commit which ultimately introduced the bug responsible for Heartbleed, essentially accepting responsibility and offering a mea culpa of sorts – no doubt in an attempt to quell the growing concern that this bug was perhaps planted by the NSA.

At the risk of sounding like a conspiracy theorist (and I will remind readers that prior to the Snowden disclosures most would have accused those speaking of the reach of the NSA’s intercept program as being a nut despite evidence of the existence of such a program being widely accepted as early as the Room 512A documents) I will admit that when news of Heartbleed broke I was immediately suspicious. The simplicity of the error and the ease of which it could be dismissed as an innocent mistake are the alleged hallmarks of the work of the agency and this essentially mirrors the style of the 2003 attempt to backdoor the Linux kernel, the only difference being the latter was caught – minimum modification yet maximum damage to the integrity of the software.

When one considers the number of websites using OpenSSL (not to mention embedded devices and appliances – which will likely remain affected while their vendors slowly push out patches) and the duration that a large portion of the internet was vulnerable it is unsurprising that some are asking questions. I would suspect that even if the NSA were not directly responsible that knowledge of the 0day would have been a very valuable thing and given their resources independent discovery is a possibility.

I wish to add a disclaimer that I am not seriously suggesting that Heartbleed was deliberate and the aforementioned developer responsible, but it is interesting to consider that it is likely now an unfortunate reality that in a post Snowden world any future vulnerabilities discovered in any software will be scrutinized and suspicions cast toward shadowy government spooks. I don’t necessarily think this is a bad thing, especially if it results in more eyes auditing the code that so many came to blindly rely on.