Improving security in s2n

In 2015 we began development of s2n, an open source implementation of the TLS/SSL protocols. We use s2n broadly at Amazon Web Services. The mission has always been to focus on security first, primarily by staying small and simple, but also by incorporating automated testing and formal verification in our development process. The testing and verification tools that we’ve sponsored in the area of provable security, including Sidetrail, are now more widely used than just s2n. Sidetrail can automatically verify that code is free of side-channels, which is an important security requirement and a deceptively hard task for humans to do through ordinary code review.

Still, automation and formal verification are not a substitute for thorough manual review, and we have a regular schedule of security reviews within the s2n team, by other teams at Amazon and by third-party reviewers. Over the last 18 months we’ve been rolling out s2n’s support for TLS1.3, the latest version of the TLS protocol, and we’ve ramped up our reviews and testing to match.

In the process, we and our reviewers identified and addressed 3 low severity security issues in s2n. We have updated all services to the latest version of s2n. If you directly consume s2n through the GitHub repository and you are using the features described below, we recommend that you update your application to the latest version of s2n. Although AWS SDKs use s2n the SDKs do not use any of the affected functionality.

Two of the issues arise from how Amazon s2n interacts with the underlying cryptography library being used, and one involves how s2n handles handshakes. Let’s start with the first two. Although s2n implements the SSL/TLS protocols, it mostly does not itself implement the cryptography being used. Algorithms such as AES, RSA, ECDH, and ECDSA are provided by libcrypto. While we support 3 different libcrypto implementations; OpenSSL, LibreSSL, and BoringSSL, these issues only arise when we use OpenSSL. This is because it’s the only implementation that supports the affected code.

Issue 1: Hardware accelerated AES-CBC

We discovered that when compiled with OpenSSL’s libcrypto, and when running on a machine that supports AES hardware acceleration, s2n’s TLS1.1 and TLS1.2 AES-CBC ciphersuites would produce repeating initialization vectors (IVs). Although s2n supplies a unique IV on every call to the underlying AES-CBC implementation, and s2n’s own “native” implementation of AES-CBC is not impacted, we identified that the IV applied by the hardware-accelerated option needed to be set in a different way.

When using AES-CBC, IVs should be unique and random. When they’re not, the encryption could be susceptible to a chosen plaintext attack. Fortunately, several factors mitigate the impact of this issue. CBC mode is s2n's least preferred option and is only included as a fallback for when AES-GCM is not available. Modern browsers, the AWS CLI, AWS SDKs, and other common callers such as CuRL never use CBC mode. Legacy clients that only support AES-CBC are almost all stuck on TLS1.0, which is not impacted by this issue. Additionally, the techniques involved in chosen plaintext attacks, including Javascript content injection and HTTP cookie inspection, generally do not apply to AWS Services. AWS’s SIGv4 authentication protocol adds defense in depth.

Issue 2: OCSP Validation

The Online Certificate Stapling Protocol (OCSP) is an extension to TLS that allows servers to present a short-lived token that proves that their certificate hasn’t been revoked. The idea is that every day or so, the servers get new tokens signed by their certificate provider, and add them to their responses. Then the client checks that the OCSP token is valid and signed. It's all pretty straightforward, and that's what s2n was doing. But s2n was not checking that the certificate name in the token matched the server's certificate. Someone who has nefariously acquired a copy of a website's revoked certificate and private key could add a valid OCSP token for a different website and trick s2n clients into continuing to connect to that server. In effect, the security is the same as having no OCSP revocation checking at all.

Although this issue clearly results in OSCP being bypassed, OCSP’s low adoption means that it is unlikely any s2n users were impacted. We do not use OCSP at Amazon, and the major browsers such as Edge, Chrome, and Safari use OCSP in a soft-fail mode that can also be bypassed. The industry has moved on to other methods for determining whether a server certificate should be trusted, such as bloom-filter based certificate revocation lists (CRLs) or certificate transparency. Regardless, we found a potential issue so we are reflecting the severity as low and fixing it in s2n.

Issue 3: Multiple handshake messages in records

At the core of the SSL/TLS protocols is a handshake that allows the client and server to securely negotiate what algorithms to use and when to start encrypting data. Outside of s2n, there’s a history of security issues related to this handshake, and s2n’s implementation of it is designed to ensure that every stage of the handshake only occurs in the correct and secure order. In fact, we’ve formally verified that s2n’s implementation matches the TLS specification.

It was a surprise to find that, while our formal verification is correct and s2n will always transition between stages in the right order, we did not verify that the handshake messages associated with the stages all have to arrive in the correct sequence of records or packets. It turns out that an attacker who writes a custom TLS implementation could trick s2n into accessing just one particular handshake message handler too early. This access would failsafe and result in a null dereference, which crashes the process.

So there’s no security break of the TLS protocol, but now we have a denial of service technique. Thankfully, it's neither efficient nor effective. In order to reach the null dereference, an attacker must still complete the computationally expensive parts of the handshake before it can be attempted. Nor can it be attempted using spoofed sender addresses, as DDOS attackers prefer. As with the other issues, we’ve fixed this, and we’re extending our formal verification to include the relationship between messages and records in the model. As an extra measure of defense in depth we’ve added a new failsafe message handler that closes connections.

As ever, you can track the progress of s2n in our GitHub repository.