Heartbleed: Considerations for Microsoft-centric organisations

Written by Readify CIO, Tatham Oddie

There has been a lot of press coverage over the last week about Heartbleed. As the vulnerable library, OpenSSL, is predominantly used in Linux and open source environments, there hasn't been as much attention applied to those of us with Microsoft-centric investments.

A quick summary: Heartbleed is a vulnerability discovered in a specific SSL implementation (OpenSSL) that allows an attacker to steal private data from the vulnerable server's memory. It is not a vulnerability within the design of SSL.

As general advice, I wanted to share the key points that we've focused on at Readify:

  • Microsoft software, like IIS, uses an SSL implementation called SChannel ("Secure Channel"), which does not exhibit the vulnerability. This does not mean that your organisation is unaffected though.
  • The most common scenario to see OpenSSL in an otherwise Microsoft web stack is edge servers. That is, performing SSL termination at load balancers and cache servers. These are often deployed as hardware appliances, external site acceleration services, or content delivery networks. In many scenarios, I find that application teams are unaware of these extra infrastructure layers, and thus may erroneously declare their application as unaffected on an initial pass. (At Readify, we use IIS ARR for publishing our internal apps to the web, providing an unaffected SChannel-based solution from end-to-end.)
  • Another scenario is embedded devices, and these are a usually harder to patch.
  • Unfortunately, due to the nature of the potential attack, you will not find any record of an attack in your logs.
  • If an affected version of OpenSSL is present anywhere in your data flow, you will need to at least patch and rotate SSL keys. You'll also need to consider any secrets that have been present on the vulnerable node, such as user submitted data and passwords. This applies even if there are further layers of SSL behind the affected device (eg, terminate-and-forward scenarios that forward to SSL-based endpoints). Remember that if you are reusing a certificate across multiple services, such as a wildcard certificate, you will need to revoke and rotate all usages, not just the vulnerable nodes.

To learn more:

If you have any questions, or would like to discuss this in the context of your own applications, please feel free to contact your Readify Principal Consultant, Account Manager or

The Heartbleed situation is important, but not dire. Still, I look forward to writing to you for more positive reasons in the future.