A brief history of OpenSSL

A brief history of OpenSSL

on Mar 2, 16 • by Andrew Pomponio • with No Comments

OpenSSL has been around since 2002 and like all software in existence, it’s had its share of bugs and vulnerabilities. This post provides a recap of the major vulnerabilities and fixes...

Home » Featured, Open Source » A brief history of OpenSSL

OpenSSL has been around since 2002 and like all software in existence, it’s had its share of bugs and vulnerabilities. The business world and personal communications world depend heavily on OpenSSL and encryption technologies. Anytime there’s a major vulnerability, it affects millions, potentially billions, of users worldwide. Company assets may be vulnerable and confidentiality also becomes compromised – this happened more than once within the last 3 years.

OpenLogic pays very close attention to OpenSSL and we are always keeping our eyes out for vulnerabilities in the platform.


In April 2014, the infamous Heartbleed bug (CVE-2014-0160) was discovered. This exploit targets private keys which utilized TLS v1.2. Attackers used the exploit to retrieve data in application memory by requesting up to 64KB per attempt until a full private key, user login information, or any other confidential data was identified. This exploit can be utilized on OpenSSL clients or servers and should be treated as critical given the fact that private keys can be compromised. Patching OpenSSL to the most recent version at the time solved the issue, but for some organizations this is easier said than done. The site heartbleed.com provides a detailed analysis of the vulnerability. This vulnerability was fixed with OpenSSL 1.0.1g, and none of the previous branches were vulnerable.

Bar Mitzvah

Also in 2014, it was discovered that a 13-year-old vulnerability in SSL/TLS allowed attackers to sniff credentials and other information during SSL sessions, giving the attack the name of Bar Mitzvah Attack. The availability and the relatively weak RC4 encryption algorithm allowed attackers to repeatedly request encrypted data until a weak key pattern allows recovery of bits and pieces of plaintext information. The remediation for this vulnerability was to remove RC4 ciphers from your TLS configuration. It was also cited that many servers default to RC4 for performance reasons, despite researchers having pointed out the vulnerabilities as far back as 2001. The full paper titled “Weaknesses in the Key Scheduling Algorithm of RC4” is available online.


In October of 2014, Google researchers Bodo Möller, Thai Duong, and Krzysztof Kotowicz discovered a vulnerability which allowed man-in-the-middle attackers to exploit a software client falling back to SSL 3.0 and weaknesses in RC4 to leak data repeated in the encrypted stream, such as secure cookies. Server configurations needed to eliminate the use of SSLv3 altogether to patch this vulnerability. Aptly named POODLE (CVE-2014-3566), which stands for “Padding Oracle On Downgraded Legacy Encryption”, it was not considered as serious as the Heartbleed bug. Shortly after this vulnerability was discovered, a similar exploit was discovered in the TLS protocol as well. Mozilla wrote a great blog about the attack and also provided the community with an SSL configuration generator to help people make sure their own configurations were secure.


It was in May of 2015 when tens of thousands of HTTPS protected websites, mail servers, and other internet services were discovered vulnerable to a new type of attack dubbed Logjam. The flaw was found in the Transport Layer Security protocol used to establish encrypted connections with servers and clients. The vulnerability was in legacy support for small and weak key sizes in the Diffie-Hellman key exchange, normally used to increase security by updating keys in the middle of an encrypted session. US Government export regulations in the 1990’s restricted encryption key sizes and strength in software to be used outside of the US, making it within the realm of possibility to break the encryption used by foreign entities. The combination of legacy support for the ability to use these weak key sizes and increases in processing power has made them relatively easy to decrypt, if a connection can be forced to use weak keys as in the Logjam attack. Ars Technica wrote a detailed piece containing more context than we have room for in this post. The vulnerability was patched in OpenSSL 1.0.2b, 1.0.1n, 1.0.0s and 0.9.8zg.


Just months prior to Logjam being disclosed, it was discovered in March 2015 that Android and iOS devices had a flaw over a decade old that made it possible for attackers to decrypt HTTPS traffic traveling from the Android/Apple device to millions of websites. The vulnerability called FREAK (CVE-2015-0204) forced the mobile devices to drop down to a lower grade of encryption when negotiating communications with websites, which made decrypting the traffic much easier for the attackers. Similar to Logjam, this attack was enabled by the weak “export-grade” encryption previously required by the US government in the 1990s, but with the RSA algorithm instead of the Diffie-Hellman algorithm involved in Logjam. The impact of this vulnerability showed that both the users and servers were impacted due to weak “export” encryption required by the US government. The fix for this vulnerability actually came from the companies of browsers like Chrome, Firefox, and Internet Explorer. Users were encouraged to upgrade their browsers as soon as the vulnerability was discovered and the browser had put out a new patched version.


It didn’t take long for the newest vulnerability to be discovered in January of this year. The OpenSSL team and maintainers have recently fixed a high-severity vulnerability (CVE-2016-0701) that made it possible for attackers to obtain the SSL key file used for decrypting communications over the transport layer. The vulnerability requires a variety of conditions to be met in order for the exploit to work, but if those conditions are met, the potential impact is high. Fortunately, the vulnerability only affects the 1.0.2 branch of OpenSSL but that does not make it any less dangerous to organizations.

The vulnerability is once again caused by a flaw in the Diffie-Hellman key exchange. Applications that use this key exchange are forced to use groups based on the digital signature algorithm to generate ephemeral keys. The default settings use the same private exponent for the life of the server process. Because this never changes, it makes the key vulnerable to a recovery attack. This vulnerability occurs in any server using a static Diffie-Hellman cipher suite. Attackers begin by sending large quantities of handshake requests to the server/client. As these requests are processed, partial secret values are revealed and the Chinese remainder theorem can be used to reduce the work in finding the rest of the decryption key.


The biggest take away we want our customers to get from all of this information, is that it is extremely important to not only keep your OpenSSL packages up to date, but to also understand what ciphers and levels of encryption your server is using. Only a properly tuned SSL configuration can protect you from all the vulnerabilities that come with OpenSSL. As such an important tool for all organizations, it deserves the same level of respect you give to securing your own home or possessions.

Mozilla has created an SSL configuration generator that you can use for free to generate a hardened and secure configuration of your servers. You can also see if your own server is vulnerable over at www.ssllabs.com/ssltest, just be sure to check the box that prevents your results from being posted publicly. If you don’t wish to use such a public tool, there’s also a nifty BASH script you can use over at testssl.sh that will allow for a more discrete internal test.

And remember, your friendly Architects at OpenLogic are always here to help with all your OpenSSL needs.

Co-authored by:

John Saboe

John is an enterprise architect on the OSS Support team at Rogue Wave Software. John has over 10 years of experience working in technology, including software development, application security, embedded and real time software, networks and protocols, software architecture, training, R&D, and technical leadership. His most recent focus has been on enterprise Java applications, open source messaging frameworks, and security.

Andrew Pomponio

Andrew is an associate enterprise architect on the OSS Support team at Rogue Wave Software. His areas of specialization include networking, Linux, network security including OpenSSL and operational troubleshooting. He has been working in the industry for three years and is acquiring new skills every day.

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top