For more than 20 years, OpenSSL has been the most widely used SSL/TLS library in use by software applications for cryptographic purposes. OpenSSL itself was a fork of the SSLeay project, now defunct. OpenSSL is free and open source, which is a huge boon for a library serving as the backbone of a secure internet. While OpenSSL is by far the most prolific way of handling cryptography from within an application, it is by no means the only option, and it is not without its problems. An almost dogmatic desire for backwards compatibility has arguably degraded the security of the open internet. With over 500,000 lines of code, OpenSSL has been commonly described as bloated. Some alternatives to OpenSSL are of a similar vintage, such as Mozilla’s Network Security Services (NSS). Others are newer, and came about as a response from large companies who wanted to reduce their exposure to vulnerabilities present in parts of OpenSSL they weren’t using.
Open Source Implementations
Mozilla’s NSS
Mozilla’s Network Security Services (NSS) is an alternative to OpenSSL which traces its history back to the SSL implementation present in Netscape Navigator. It is still actively developed, is FIPS compliant, and makes a concerted effort to allow drop-in replacement of newer releases without recompiling code.
LibreSSL
After the high-profile vulnerability HeartBleed in 2012 which allowed for disclosure of data which was supposed to be encrypted, the BSD team wondered whether some of the practices of the OpenSSL team were to blame. OpenSSL was forked, and the codebase significantly altered to remove legacy cruft. To this day, OpenBSD relies on LibreSSL as the library used by the Operating System itself. Gentoo however recently dropped support, which can be seen as a bellwether of LibreSSL falling out of favor – the Gentoo project perhaps more so than any other values user choice at all cost.
BoringSSL
BoringSSL was created as a fork of OpenSSL in 2014 by Google to meet its own evolving needs, and though this library is open source, Google does not recommend its use by third parties. Over time, many of the ideas introduced by BoringSSL have been merged back into the main OpenSSL project itself. One interesting facet of BoringSSL is that it rejects the concept of renegotiation, as this library feature has consistently been the source of new and interesting bugs ripe for exploitation in OpenSSL over the years.
Bouncy Castle
Bouncy Castle was originally written as an API for SSL/TLS for use by Java in 2000, but a version for c# was released shortly thereafter. Bouncy Castle is well known for top notch enterprise support, making it a compelling choice for new development. Bouncy Castle is maintained by the Australian registered Charity “The legion of the bouncy castle”.
Proprietary Implementations
SChannel
Perhaps the most widely known proprietary implementation of SSL/TLS is Microsoft’s Secure Channel (SChannel). SChannel is the operating system component of Microsoft Windows (both clients and servers). SChannel is notorious for lagging behind OpenSSL and its derivatives in terms of features – only as of Windows 11 and Server 2022 does Windows support TLS 1.3, which was released more than 5 years ago.
BSAFE
BSAFE was originally owned by RSA, and they attempted to fully sunset this product line in 2017. In 2020, Dell took over the product and has continued its development. One can read between the lines here and surmise that large and lucrative enterprises or government entities likely heavily rely on this software and the cost of moving off of it outweighs the cost of continuing to use it.
Conclusion
Ultimately, it is very likely that OpenSSL will continue to be the most popularly used implementation of SSL/TLS worldwide. These alternatives though have continued to shape and mold OpenSSL through the power of healthy competition. Simultaneously, many of the original problems which lead to the birth of alternatives have been addressed in the OpenSSL project – for example, OpenSSL 3.0 does away with the swathes of legacy cruft BSD so staunchly opposed. It will be interesting to see how implementations of SSL/TLS continue to grow and evolve in the next few years as we face new challenges.