Amazon has released s2n, a minimalist replacement for the TLS manager libSSL library in OpenSSL, following long-standing problems and high-profile bugs in OpenSSL, such as the Heartbleed vulnerability. Amazon will begin implementing s2n in AWS services over the next few months; AWS users will not need to take any action to support it.

What this is, and what this is not

OpenSSL contains two main libraries: libSSL (which handles the implementation of the TLS protocol) and libCrypto (which performs the cryptographic functions involved in protecting the data sent over the TLS protocol). Altogether, OpenSSL sits at over 500,000 lines of code, and has extensive support for things that are troublingly difficult to do securely, such as session renegotiation, and for protocols that are not particularly common for most web traffic, such as DTLS.

Amazon’s s2n is a replacement for libSSL, though it relies on either OpenSSL, the LibreSSL fork created by the OpenBSD team after Heartbleed, the BoringSSL fork created by Google, or the Apple Common Crypto framework.

According to the release notes:

“s2n implements SSLv3, TLS1.0, TLS1.1, and TLS1.2. For encryption, s2n supports 128-bit and 256-bit AES, in the CBC and GCM modes, 3DES, and RC4. For forward secrecy, s2n supports both DHE and ECDHE. s2n also supports the Server Name Indicator (SNI), Application-Layer Protocol Negotiation (ALPN) and the Online Certificate Status Protocol (OCSP) TLS extensions. SSLv3, RC4, and DHE are each disabled by default for security reasons.”

Why this is more interesting than a fork

According to Amazon’s VP of Security Engineering Stephen Schmidt, in this blog post introducing s2n, over 70,000 lines of code in OpenSSL are concerned with processing TLS sessions. In contrast, s2n is just over 6,000 lines. The primary benefit of this reduction is having a small and easily auditable code base, which has the added benefit of preventing the feature sprawl that has made OpenSSL difficult to manage.

Additionally, forks of OpenSSL are bound by OpenSSL’s original license, which is troubling from a free software standpoint. OpenSSL is dual licensed under both the OpenSSL License and the SSLeay License. Under normal circumstances, “dual licensed” indicates that the software in question can be used with either of the applicable licenses. In the case of OpenSSL, dual licensed indicates that the user is bound to both of the licenses.

The licenses involved are — at best — nonstandard, which in the wake of Heartbleed was called into question as being a factor that limited community involvement, something which potentially would have caught or mitigated the issue far in advance. Additionally, the licenses used in OpenSSL are not GPL compatible, a point of contention that dates back over a decade.

Potentially unwanted backward compatibility

In late June 2015, the call for deprecation of SSLv3 was published in RFC 7568. SSLv3 was originally released in 1996, and has since been superseded with three revisions of the TLS protocol, though it continues to be used in certain circumstances, mostly involving legacy systems. The push to deprecate SSLv3 started in earnest in October 2014 following the high-profile POODLE vulnerability.

RC4, the only non-block cipher used in SSLv3, is considered to have a variety of cryptographic weaknesses, which have resulted in an RFC calling for the deprecation of that cipher in all versions of TLS.

Amazon’s s2n includes support for SSLv3 and RC4, though as noted above, support is disabled by default.

What’s your connection?

Does the prospect of a minimalist TLS connection library put you at ease compared to the size of the OpenSSL codebase? For your deployments, will you use s2n in conjunction with OpenSSL (or a fork thereof) for encryption? Have you already deployed an OpenSSL fork in the wake of the Heartbleed bug? Share your security strategies in the comments.

Note: TechRepublic and ZDNet are CBS Interactive properties.