Important note about “Heartbleed” OpenSSL security flaw


A serious security flaw was discovered in OpenSSL several days ago. It is related to the Heartbeat TLS/DTLS extension and may cause critical data leaks.

Details of the issue.

The Heartbeat TLS/DTLS extension provides keep-alive functionality to a TLS/DTLS session without renegotiation. In fact it is a pretty simple request-response protocol. Its implementation in OpenSSL was a bit incorrect, an array bounds check was missing and it could be used to reveal up to 64kb of memory to another endpoint. It is very bad: sensitive data may be stored in system memory including private keys, passwords and so on. It means that an attacker has the ability to steal such data. The worst news is that there are no traces in attacked system at all: no crashes, no warning logs.

Affected OpenSSL release versions list: 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1

The issue was fixed in OpenSSL release 1.0.1g

See for more details. Technical information including links to patches is available at


The security impact caused by this flaw is huge. First of all OpenSSL is a very popular implementation of the SSL/TLS protocol and it is very widely used for securing websites, email, XMPP, VPN communications, etc. As long as the bug allows a remote attacker to read process memory data, it allows them to steal private keys used by OpenSSL. As a result all private keys which were ever used by vulnerable OpenSSL versions should be as assumed to be compromised. Stolen keys allow attackers to build MiTM attacks and get users’ sensitive data including passwords, credit card numbers, etc.

What should be done as soon as possible?

The following steps are highly recommended to mitigate the consequences of this issue.

  1. Check the OpenSSL version which is used in your services. A list of vulnerable versions is provided above. Many major vendors have already published security updates to OpenSSL and it is necessary to update to any non-vulnerable version as soon as possible. If you already have a non-vulnerable version, check if you had a vulnerable one before. For HTTPS testing you can use, but note that every SSL/TLS connection is potentially vulnerable at the moment, not only HTTPS.
  2. All TLS certificates used by vulnerable OpenSSL versions should be revoked and replaced. Their private keys should not be used anymore.
  3. It is necessary to identify what infrastructure objects could be potentially attacked, and what additional data may be leaked using stolen TLS private keys. It makes sense to demand users reset their passwords and notify them that sensitive data may have been leaked.
  4. It makes sense to perform an infrastructure security audit to check if there are any backdoors installed by attackers manually if your system was hacked using stolen private keys.
  5. It is necessary to check that any services you use are not vulnerable at the moment. Vulnerable third-party services may affect your clients.
Sign Up for Updates!

Subscribe now to receive industry-related articles and updates

Choose industries of interest
Thank You for Joining!

You will receive regular updates based on your interests. No spam guaranteed

Add another email address
Read more
Sign Up for Updates!
Choose industries of interest
Thank You for Joining!

You will receive regular updates based on your interests. No spam guaranteed

Add another email address
We are glad you found us
Please explore our services and find out how we can support your business goals.
Get in Touch
Download the white paper Glancing Forward into 2021: An Industry by Industry Outlook

Explore digital trends and unanticipated benefits engendered by the pandemic, which are likely to last in 2021.