Adrian Hayter of CNS Hut3 has recently discovered that a majority of the widely available tools companies are using to check to see if they are susceptible to heartbleed are giving false results and leading companies to believe they are safe from the vulnerability when in fact they may not be.

His Blog goes in to this in great detail. Here he explains the problem:

When a person starts an SSL/TLS connection, they send the version number of the SSL/TLS protocol they want to use. There are 4 that are generally used:

SSLv3.0, TLSv1.0, TLSv1.1, and TLSv1.2

If the server supports the one that they select, the connection can continue. If the server doesn't support the protocol that the client selects, then it will respond by either dropping the connection or trying to negotiate a protocol which the server does support.

In a lot of the scripts, including the original proof of concept, the script always sends the version "TLSv1.1". If the server doesn't support TLSv1.1, it will either reject the connection or suggest another version. However, the scripts do not check for either of these and assume that any response that isn't successful means that the server is not vulnerable. This is the first bug.

A number of scripts (including the Nessus and Metasploit checks) do support multiple versions of TLS, which is good. However, they also suffer from the second bug:

Along with the version number, the person connecting to the server also sends a list of "cipher suites" that they support. The cipher suites are taken from a pre-defined list, and the server will choose one to use for the encryption that takes place later on in the connection. However, once again, if the server does not support any of the cipher suites that the client sends, the connection will disconnect.

Most of the scripts I've looked at only tell the server that they support about 51 cipher suites. That may sound like a lot, but there are at least 318 cipher suites that are defined by IANA. Granted, most servers will support at least one of the ciphers in the list of 51, but there could be instances where a server does not support any of them, and in these cases, the server would respond with an error, which the scripts interpret as "not vulnerable".

The third bug I found didn't actually relate to the TLS setup at all, but was rather with the way most of the scripts downloaded the server responses. It was possible on slow connections for the download to timeout before it was fully received, and the script would return an empty response, which it would again interpret as "not vulnerable", even if the partially downloaded response would have been enough to confirm the vulnerability.