Researchers poke hole in custom crypto built for Amazon Web Services
Underscoring just how hard it is to design secure cryptographic software, academic researchers recently uncovered a potentially serious weakness in an early version of the code library protecting Amazon Web Services.
Ironically, s2n, as Amazon’s transport layer security implementation is called, was intended to be a simpler, more secure way to encrypt and authenticate Web sessions. Where the OpenSSL library requires more than 70,000 lines of code to execute the highly complex TLS standard, s2n—short for signal to noise—has just 6,000 lines. Amazon hailed the brevity as a key security feature when unveiling s2n in June. What’s more, Amazon said the new code had already passed three external security evaluations and penetration tests.
Amazon’s June 30 announcement was only a few hours old when Royal Holloway, University of London Professor Kenny Paterson and his colleagues met for lunch at a nearby pub to discuss the security of s2n. Five days later, they presented Amazon engineers with a report showing that the newly unveiled s2n was vulnerable to “Lucky 13,” a TLS attack unveiled in 2013 that made it possible to recover encrypted browser cookies used to access restricted parts of a website. Amazon engineers promptly fixed the errors. In a blog post, Amazon officials said the the vulnerable version of s2n was never used in production and that the proof-of-concept attacks “did not impact Amazon, AWS, or our customers, and are not the kind that could be exploited in the real world.”