Amazon today released to open source its own TLS implementation called s2n, which stands for signal to noise.
While admittedly not meant to be a replacement for OpenSSL, for example, s2n is a slimmed-down crypto implementation analogous to libssl, the OpenSSL library that supports TLS. Amazon chief information security officer Stephen Schmidt said that s2n will soon be integrated into certain Amazon Web Services, and the experience will be seamless for users; no changes will be required to apps and none will be made that will affect interoperability, Schmidt said in a post on the AWS security blog.
“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,” Schmidt said. “As a result of this, we’ve found that it is easier to review s2n; we have already completed three external security evaluations and penetration tests on s2n, a practice we will be continuing.”
The relatively small number of lines of code avoids the complexity—and subsequent bugs and security issues—that the OpenSSL team is dealing with, for example. OpenSSL, Schmidt said, has more than 500,000 lines of code, including 70,000 involved in TLS processing.
“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,” Schmidt said, adding that s2n has already undergone two external code reviews—one by a commercial security vendor—and has been shared with crypto experts in the security community.
OpenSSL, meanwhile, is on a recovery track after a rocky 18-month period during which Internet-wide vulnerabilities such as Heartbleed tore open the curtain on the frailty of the under-funded and under-resourced open source project. OpenSSL’s maintainers are in the midst of a sizable code cleanup and instituting formal processes for critical changes. Funding from the Core Infrastructure Initiative allowed OpenSSL to hire two full-time employees and fund help to handle bug reports, code reviews and changes.
s2n certainly attempts to steer clear of that kind of complexity, and afford users the ability to hurdle the software upgrades and certificate rotations that accompanied Heartbleed and other Internet-wide bugs in the last year and a half, Schmidt said.
Documentation accompanying the source code, available on Github, says that s2n implements SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2. It supports 128-bit and 256-bit AES in CBC and GCM modes, 3DES and RC4, for encryption. It also supports DHE and ECDHE for forward secrecy. Outdated crypto such as SSLv3, RC4 and DHE are disabled by default, however. SSLv3, for example, was recently officially deprecated by the IETF. The protocol, which has long been supplanted by TLS, is responsible for a number of fallback attacks, most notably POODLE and BEAST. s2n, however, does lack x509 certificate parsing, therefore it’s meant to be built with one of the OpenSSL-derived libraries, for example.
It also includes positive and negative unit tests and end-to-end test cases, Amazon said.
“One of the real challenges in existing TLS libraries like OpenSSL is that data structures and state flows are often difficult to test with automated tools,” said Kenneth White, a security researcher and director of the Open Crypto Audit Project. “By making unit and integration testing a first class citizen from the beginning, the AWS team is really promoting an emphasis on software quality assurance, and that benefits all their users.”
Amazon said also that s2n provides every thread with two random number generators.
“One for ‘public’ randomly generated data that may appear in the clear, and one for ‘private’ data that should remain secret,” the documentation says. “This approach lessens the risk of potential predictability weaknesses in random number generation algorithms from leaking information across contexts.”
