At the beginning of April, a CVE (Common Vulnerabilities and Exposure) notice was posted which gave the world visibility of a bug in the OpenSSL software library which could potentially be used to steal information which was thought to be secure. Although Microsoft products are not affected by this vulnerability as they use a different SSL implementation, there are potential implications of Heartbleed which must be considered if you’ve implemented SSL on a Microsoft product.

I’ve heard noise about Heartbleed. Tell me about it.
You’re right, there’s a lot of talk on the internet at the moment about big name, famous services patching their OpenSSL implementations so they are no longer vulnerable to Heartbleed (for a full description of how this vulnerability take a look at heartbleed.com), and there’s also a big uncertainty because nobody as yet has shown an attack in the wild which has utilised Heartbleed as the attack vector. However this is being taken very seriously because the Heartbleed attack is ‘stealthy’, it’s difficult to detect, and could have been ongoing for a long time.

OK it does sound a little serious, what can people steal?
Heartbleed can not only theoretically lead to the exposure of usernames and passwords – and you’ll see loads of news, tweets and Facebook posts about changing your password – it can leak the secret keys used to make the SSL certificates we’ve relied on for years to keep our web traffic safe. If a hacker can gain these secret keys, he can pretend to be your site or decrypt the secure traffic to and from your site.

But you said Microsoft products don’t use OpenSSL?
That’s right. Microsoft have their own implementation of software to enable secure communications, it’s called Secure Channel. However, the certificates used to protect communications to a Microsoft channel can still be compromised by Heartbeed.

Tell me more…
OK – it goes like this. SSL certificates are expensive to acquire and to manage. Lots of people use a few features in the standard which defines how these things work so that they can secure many servers with one certificate. When you request a certificate you can add fields called ‘Subject Alternate Names’ to these (basically a list of aliases) so that you can use one certificate for many services, or you could also purchase a wildcard certificate that can be used to protect any server in your domain. There are pros and cons to each of these methods, but that’s not for discussion here.

So why does that make my SharePoint server vulnerable to Heartbleed?
It doesn’t – however if you’re securing your SharePoint server with a wildcard certificate, or a certificate that has SANs in it, and that certificate has also been used on a server running a vulnerable version of OpenSSL, your certificates could have been compromised.

Which means?
The upshot of this is that secure traffic to your SharePoint, Exchange, CRM, or IIS hosted app could be compromised!

I don’t like the sound of that! What can I do?
Fortunately there’s an easy way to ensure that your secure communications are once again secure. Once you’ve made sure that any service you have that’s running OpenSSL has been patched and made secure, you can ask the Certificate Authority who issued your certificates to revoke these old ones and issue new. Fortunately that’s normally a process you can undertake from their web portals, and should only take a few minutes to generate.