Microsoft Azure is Safe from Heartbleed, VMware – Not so Much

Unless you've been stowed away in a cave somewhere, you're aware of the massive bug in the Internet's secure communications layer – the piece that's supposed to protect our personal information and privacy from being openly available to anyone with malicious intent. The problem results from how many vendors used an open source technology to provide supposed security services.

This is a mammoth problem and some have estimated that it may take 10 years to clean up completely. Many vendors are hustling to put in fixes and many more are issuing advisories to explain which specific services are affected. If you want a well-defined description about Heartbleed, I suggest reading through the excellent post by Troy Hunt. This is probably the best summation I've seen. Read it here: Everything you need to know about the Heartbleed SSL bug.

There have been a bunch of hits against the Cloud over the past year, effectively curbing its use and causing many businesses to continue to question its viability as a secure solution. One of the biggest snags in recent history was the Snowden revelations about the far reaching, evil tendrils of the NSA. But, Heartbleed trumps even that. As news started to spread, one of the very first questions posed was how this would affect Cloud adoption?

It boils down to this: Vendors that chose to use the open source implementation are vulnerable. This includes companies like Google, Amazon – even VMware. VMware has now posted a knowledge base article highlighting the products that are confirmed to be affected and those that are not. The "affected" list is just as long as the "unaffected" list. If you're using VMware as a virtualization provider, you may want to consider your options.

Microsoft, on the other hand, does not use OpenSSL. Microsoft Azure uses Secure Channel, which is not at all susceptible to the Heartbleed vulnerability. And, further, the whole range of Windows Server versions 2003 through 2012R2 and versions of IIS also use the same Secure Channel technology. So, unless you manually implemented OpenSSL to replace Secure Channel on these servers, you're safe.

This is a two year old bug that somehow went unannounced. The ironic thing is that it's the most recent versions of OpenSSL that are affected. Older versions are not. And, this brings up a very good question. Who exactly is reviewing open source code these days? The original intent of open source software was to bring thousands of reviewers together (many eyeballs) to ensure things like Heartbleed wouldn't happen. Either the open source community just missed this one, the open source model is flawed, or there are no security experts left in open source. I'm sure there's a litany of other excuses that could be applied here, but the fact remains that somehow the open source community had two years to identify and fix this, and they didn't. There are no valid excuses.

Aidan Finn puts it this way:

The lesson here is simple: Building alleged enterprise-class software where no-one is responsible for trustworthy computing reviews is negligent.