A vulnerability was recently discovered in Amazon Web Services' Signal to Noise, which is AWS' customized implementation...
of the TLS protocol. AWS addressed the s2n flaw and the related Lucky 13 attack on its blog recently and patched the flaw. However, the bigger question for the security and cryptographic communities is this: Are custom, open source versions of SSL/TLS risky for cloud providers? To get to the answer, we need to consider a number of factors.
The unlikely Lucky 13 attack
First, the Lucky 13 attack -- which was published in 2013 -- is incredibly complicated, requiring precise timing measurements of modified packets between a client and a server using SSL/TLS. For an attacker to accomplish this, they would have to inject custom script code into the victim's browser and then carefully monitor minute timing differences for a huge number of modified packets being sent back and forth. While this is certainly possible hypothetically, the attacker would ideally be on the same network as the server, and that is enormously impractical for most implementations of a timing-focused attack like Lucky 13. This may be slightly more practical using the datagram version of TLS, but is still improbable.
Attacks on s2n
To truly affect AWS users who rely on s2n, the attacker would need to be in the Amazon network and on the same network segment as the servers running TLS services. Attackers running systems in AWS is definitely plausible, but being able to carefully monitor the same network as the TLS services in question is unlikely unless the target system was also compromised to begin with. According to the team at Amazon, s2n was never really susceptible to the attack in the first place, even when the flaws were discovered. If Amazon's statement in its blog post is to be believed, s2n only made attacks like this "…tens of millions of times more difficult for attackers, rather than the trillions of times more difficult that we had intended."
This doesn't change the fact that these kinds of attacks will eventually happen, and at some point they'll be simpler to execute and more feasible than the Lucky 13 attack. However, the argument can be made that Amazon is taking some of the right steps in trying to fix the mess that is Internet cryptography, in particular with SSL and TLS. Critics of s2n argue that s2n, which only has 6,000 lines of code compared to the 70,000 involved with OpenSSL, is not representative of the entire OpenSSL suite.
Those critics are likely right, but Amazon's implementation works for its customers, and that's what it's focused on. Amazon sought to implement the most modern and secure implementation it could with a more accessible and auditable code base, which helps security researchers find flaws where they exist and ideally fix them just as readily. Simply reducing the lines of code will not always make complex protocol implementations more secure by any means; it could even make them worse, as Robert Hansen of WhiteHat Security pointed out in this article. However, given the large number of major flaws found in OpenSSL over the past several years, looking for a new alternative might make sense in this case.
Is Amazon S2n safe?
Any time a vendor introduces a custom version of cryptographic protocols, the information security community should be wary. However, we can't be totally closed-minded, either. It's imperative that we review and scrutinize new efforts like s2n, but Amazon seems to be very open with its implementation and willing to work closely with the research community to investigate weaknesses and fix them in the most optimal way possible. Customers of any vendor using specialized protocols and code libraries should pay close attention to what they're doing, demand openness and integrity, and embrace security research that helps reduce vulnerabilities and improve the state of cloud security.
Check out the business case for s2n TLS implementation
Find out if a client puzzle can improve TLS protocol security
Learn how the Logjam vulnerability affects TLS encryption