Amazon launches open source TLS implementation "s2n"

News by Rene Millman

Amazon manages to cram OpenSSL alternative into just 6,000 lines of code

Amazon has unveiled an open source alterative to OpenSLL that implements TLS in just 6,000 lines of code.

The code, dubbed s2n (signal to noise), has been developed in response to problems surrounding OpenSSL, most notably the HeartBleed vulnerability that left infosec professionals scrambling to patch up last year. In the meantime, other problems, such as Logjam and Freak, have also made the search for an alternative to OpenSSL a priority for many organisations.

Stephen Schmidt, Amazon's vice president of security engineering said in the blog post, that the aim of s2n was to “simplify our TLS implementation”.

“S2n is a library that has been designed to be small, fast, with simplicity as a priority. S2n avoids implementing rarely used options and extensions, and today is just more than 6,000 lines of code,” he added.

He explained that the challenge has been that the TLS protocol, with all of its optional extensions has “become very complex”.

“OpenSSL, the de facto reference implementation, contains more than 500,000 lines of code with at least 70,000 of those involved in processing TLS. Naturally with each line of code there is a risk of error, but this large size also presents challenges for code audits, security reviews, performance, and efficiency,” said Schmidt.

However, the new s2n replaces only one of OpenSSL's two main libraries; Libssl. This implements TLS. Libcrypto, with is OpenSSL's general purpose cryptographic library has no equivalent in s2n.

Schmidt said that s2n has not yet been deployed within Amazon but over the next few months will begin to integrate it into several AWS services.

“TLS is a standardised protocol and s2n already implements the functionality that we use, so this won't require any changes in your own applications and everything will remain interoperable,” he added.

Rapid7's security engineering manager, Tod Beardsley, welcomed Amazon's decision to improve TLS in a “responsive, open source way”.

“After Heartbleed, we saw something similar from Google with their release of BoringSSL, as well as OpenBSD's volunteer-driven LibreSSL. All of these projects promise a stripped down version of SSL/TLS with an eye toward excising the cruft that leads to vulnerabilities and weird code paths in OpenSSL,” he said.

Beardsley added that the small code base would make manual code audits orders of magnitude easier.

“I don't expect this extremely small base to last, though, in its current form, since there is no built-in support for major functionality like certificate parsing,” he said.

“So, it's a small code base which is still going to depend on other projects for any sort of production use. That said, it seems like a good idea to separate the TLS functionality from the more general cryptography functionality, so bugs and features there can be fixed and tested in isolation”

Ivan Ristic, director of engineering at Qualys, told that because TLS has to operate in many environments it has “many extensions that change how it operates but don't necessarily increase security”.

“Additionally, there are some extensions not widely supported and can't be relied upon,” he said.

“Removing such extensions reduces the attack surface (bugs are most commonly found in code that's seldom used) and thus improve security. I apologise for mentioning Heartbleed, but it's a perfect example in this case: The Heartbleed bug was in the heartbeat extension that newer versions of OpenSSL had enabled, but virtually no client supported.”

Ristic added that the smaller the codebase the better.

“Also very significant in this case is that Amazon is committed to security via regular third-party reviews. Then, the fact that it was written from scratch means that they were able to learn from past mistakes, and improve the design of the library,” he said.

Any worries that s2n may not be for every organisation was quickly dispelled by Ristic. He said that s2n appears to support all the good parts of TLS. “For example TLS 1.2, authenticated GCM) suites, and so on. It also supports some older features that are still necessary to support older clients. In a nutshell, I think s2n could largely be used on any public server that doesn't need client authentication (see below).”

The issue of s2n not supporting certificate validation didn't seem too much of a problem.

“It's an issue in the sense that, if you need certificate validation, you can't use this library. At least not yet - we don't know if these features will be added over time,” said Ristic.

“However, the only situation where a server would need to validate certificates is when client certificates are used. Most public web servers don't do this.”

“Also, strictly speaking, a TLS library shouldn't actually deal with certificate validation at all; it's a separate problem. For that you'd typically use a separate library. It just so happens that common libraries (eg, OpenSSL) have grown to handle many different problems,” he added.


Find this article useful?

Get more great articles like this in your inbox every lunchtime

Video and interviews