![Lead Image © Ilya Masik, fotolia.com Lead Image © Ilya Masik, fotolia.com](/var/ezflow_site/storage/images/archive/2014/23/security-after-heartbleed-openssl-and-its-alternatives/po-20839-fotolia-ilja_masik_fotolia-skifahrer_resized.png/104138-1-eng-US/PO-20839-Fotolia-Ilja_Masik_Fotolia-Skifahrer_resized.png_medium.png)
Lead Image © Ilya Masik, fotolia.com
Security after Heartbleed – OpenSSL and its alternatives
Defying the Danger
In most corporations, security updates take place without much of a stir. In fact, the lion's share of vulnerabilities remain unnoticed to the public; they fly past admins in the form of security advisories. If a vulnerability makes it into the mainstream media, however, admins can be sure it will be a really big thing. The OpenSSL bug Heartbleed [1] (Figure 1) made it into many major websites, and even into living rooms with news broadcasters reporting on it in prime time.
![](/var/ezflow_site/storage/images/archive/2014/23/security-after-heartbleed-openssl-and-its-alternatives/figure-1/104142-1-eng-US/Figure-1_large.png)
Heartbleed cannot be assessed negatively enough. Because it is based on a simple function that most clients don't actually use but is enabled as part of the OpenSSL [2], default configuration, keys, certificates, and basically everything that happens in main memory, was freely readable – both in the client-server direction and vice versa. Heartbleed really hurt.
Additionally, the Heartbleed phenomenon seemed to undercut a central mantra of the FOSS movement. The FOSS community likes to claim that open source
...Buy this article as PDF
(incl. VAT)