Korrektur der Heartbleed-Katastrophe
Donnerstag, 15. Mai 2014
Eine Übersetzung für diesen Text ist nicht verfügbar.  Bitte wählen Sie die englische Version.
In early April 2014 two independent IT security specialists from Codenomicon and Google Security discovered a flaw introduced into OpenSSL in December 2011. This article does not cover the happening itself, but focuses on common misunderstandings and wrong interpretations with regards to the catastrophe.

One common misinterpretation was that "Heartbleed", which is the way the flaw/bug was prematurely called, would only affect current versions of OpenSSL. However the truth is that older versions were affected as well – number 1.01 and 1.02 to be more precise [1].

OpenSSL is a piece of software to encrypt traffic of connections on transport layer, which mostly affects TCP connections. The TCP/IP-stack is the dominant protocol-stack on the internet consisting of about 500+ different protocols. Since a lot of higher-level protocols, such as HTTP partially rely on encryption, TLS/SSL is employed on a regular basis to satisfy this constraint. For a disambiguation between TLS/SSL and SSH we suggest the article on Snailbook for reference [2]. Basically OpenSSH is a protocol with several sub-protocols. (e.g. for multiplexing, password-based authentication, terminal management, etc.) which implements non-PKI authentication on S (session), P (presentation) and A (application) layer of the ISO:OSI model. OpenSSL on the contrary employs PKI and resides on T (transport) layer of the ISO:OSI model.

As a further note OpenSSL is not the only implementation of TLS/SSL. The Free Software Foundation develops and maintains the GnuTLS software package, with its independent codebase for years as an alternative to OpenSSL [3]. There are even more implementations of the two protocols from various companies and organizations – some of them under different license and therefore closed source software and/or non-free.

Another misconception was to believe that in any case someone would be able to steal the PK (private key) by stealing the server certificate offhand. Also an attacker would not be able to somehow generate, extract or infer a public key from a server certificate, since that would undermine the whole cryptographic scheme at large. However the certificate does indeed contain the public key which is required mandatory for later generation of exchange-information during connection establishment. The Heartbleed bug changes the above situation though and enables potential attackers to actually force-extract the private key from the assigned RAM (Random Access Memory) area. Affected are some of the popular (web)servers, like Apache HTTP Server or Lighttpd [4]. These servers (still) tend to temporarily load the private key into a section of the RAM space they occupy during operation. The results of the "Heartbleed Challenge" initiated by Cloudflare showed however that a significant amount of resources would have to be assigned to a successful key extraction.

To ensure the server's safety one should therefore not only upgrade all of the system's sources or packages but also re-generate its private key(s) and issue a CSR (Certificate Signing Request) thereupon. Afterward it's paramount to safely physically store the new private key and restrict all access to it. The old private key should also be contained along with the old server certificate to issue a CR (Certificate Revocation). Of course we know the limitations of the revocation process, but mention it here for completeness [5]. Ultimately it is important to understand that a simple re-issuing of the server certificate without re-generation of the corresponding private key does never provide maximum security in the case of a previous successful Heartbleed attack. Unfortunately even 74 percent of the world's biggest public companies (Global 2000) were yet unable or unwilling to act accordingly [6].

In the context of the potential successful extraction of private keys from servers one should reconsider the implementation and/or activation of PFS (Perfect Forward Secrecy). That property of exchange protocols is suitable to ensure the safety of past TLS/SSL sessions. Therefore it doesn't matter whether a server was compromised already (regarding past sessions and their valuable data in transit) since PFS enables the regeneration of session keys in regular intervals. As a result it would not be possible to decrypt larger amounts of sessions cryptographically secured by one single combination of keys and certificate, because it would definitely mean a tremendous effort in the reconstruction of past sessions to clear-text. In combination we also suggest the use of HSTS to prevent potential attackers from downgrading connections [7].

Since more Heartbleeds may be on the horizon systems administrators and engineers alike should implement all available security-measures at hand, also to mitigate completely different potential threats to cyber and information security in advance.

Zuletzt aktualisiert (Mittwoch, 1. April 2015)


  2022-01-08 ✴ 20:00 UTC




  ᐊ 1&1 INTR. AG  CDN


Sollte ✛ΔO »counter- intelligence« anwenden?
∘ Ja, es gibt Bedarf für solche Operationen.
∘ Nein, denn dies zu tun ist zu risikoreich.


Bookmark site Via Cmd oder Strg + D
Bookmark page Via Cmd oder Strg + D


  Besucher: 788.250+ ℮


  25 Jahre Linux



  Code of Arms: Frankfurt


  Anlage: Offen und in Betrieb
©  2003 - 2023   TRON-DELTA.ORG  (NGO)   –   Nongovernmental  Intelligence  Organization
Portal v5.06.102 R 1 mit ✛ΔO LXCMS v1.1