S2n Is Now Handling 100 Percent of SSL Traffic for Amazon S3(aws.amazon.com)
aws.amazon.com
S2n Is Now Handling 100 Percent of SSL Traffic for Amazon S3
https://aws.amazon.com/blogs/security/s2n-is-now-handling-100-percent-of-of-ssl-traffic-for-amazon-s3/
25 comments
It only replaced half of OpenSSL, but it replaces the half which has been responsible for almost all of the worst vulnerabilities.
Erlang has the `ssl` application which is built on top of `crypto`. The latter uses OpenSSLs libcrypto, but ssl is written in Erlang.
Historically, whenever there is an OpenSSL vulnerability, it doesn't affect the ssl application, and so Erlang isn't vulnerable. In short, corroboration.
Historically, whenever there is an OpenSSL vulnerability, it doesn't affect the ssl application, and so Erlang isn't vulnerable. In short, corroboration.
Not the whole half either it seems. They use openssl for ASN.1 / certificate parsing too (opensl/x509.h) here:
https://github.com/awslabs/s2n/blob/b9e3636db98e4ba765fb2193...
https://github.com/awslabs/s2n/blob/b9e3636db98e4ba765fb2193...
I don't think that you have to replace everything, but only:
- what you actually use
- what is broken
I think s2n does exactly that.
- what you actually use
- what is broken
I think s2n does exactly that.
Is there a FIPS 140-2 validated version of "s2n" somewhere ? I couldn't find anything close to it on the FIPS 140-2 validated products list.
If not, how does Amazon get away with using S3 as part of GovCloud, which purports itself to be NIST SP 800-53 compliant, one requirement of which is NIST SP 800-53 Control SC-13 ( https://web.nvd.nist.gov/view/800-53/Rev4/control?controlNam... ), which says, while it does not mandate cryptography, if you do use cryptography to satisfy any of the other controls the cryptography must be certified to the appropriate level (classified data must use NSA-approved cryptography, digital signatures must use FIPS-validated cryptography).
This is a base control for NIST SP 800-53, which is a requirement for FedRAMP.
If not, how does Amazon get away with using S3 as part of GovCloud, which purports itself to be NIST SP 800-53 compliant, one requirement of which is NIST SP 800-53 Control SC-13 ( https://web.nvd.nist.gov/view/800-53/Rev4/control?controlNam... ), which says, while it does not mandate cryptography, if you do use cryptography to satisfy any of the other controls the cryptography must be certified to the appropriate level (classified data must use NSA-approved cryptography, digital signatures must use FIPS-validated cryptography).
This is a base control for NIST SP 800-53, which is a requirement for FedRAMP.
We're actively working on building a FIPS-compliant libcrypto with s2n. There are some quirks to the libcrypto API when FIPS mode is enabled. If this is something you would be interested in, feel free to fire up an issue for tracking: https://github.com/awslabs/s2n/issues
Keep in mind that FIPS-compliant and FIPS-validated are entirely different things and that NIST SP 800-53 specifies FIPS 140-2 validated operations for digital signatures.
[deleted]
The body text is a bit more qualified than the headline:
> we have replaced OpenSSL with s2n for all internal and external SSL traffic in Amazon Simple Storage Service (Amazon S3) commercial regions
I suspect that "commercial regions" excludes govcloud.
> we have replaced OpenSSL with s2n for all internal and external SSL traffic in Amazon Simple Storage Service (Amazon S3) commercial regions
I suspect that "commercial regions" excludes govcloud.
Darn. I should have read the fine article, but I was really hopefully that there would be a migration path off OpenSSL... RedHat has FIPS validated most of their software, but it is expensive and slow work that someone building from source cannot leverage, unlike OpenSSL.
Maybe the title should be changed, since it implies that 100% of the SSL S3 traffic is using s2n ?
It appears to me that only the specification of the encryption algo has to be FIPS 140-2 approved. There is a list with approved functions and techniques.
FIPS PUB 140-2 Annexes: Annex A: Approved Security Functions (Draft 04-08-2016)
Annex B: Approved Protection Profiles (Draft 11-18-2015)
Annex C: Approved Random Number Generators (Draft 01-04-2016)
Annex D: Approved Key Establishment Techniques (Draft 10-08-2014)
FIPS PUB 140-2 Annexes: Annex A: Approved Security Functions (Draft 04-08-2016)
Annex B: Approved Protection Profiles (Draft 11-18-2015)
Annex C: Approved Random Number Generators (Draft 01-04-2016)
Annex D: Approved Key Establishment Techniques (Draft 10-08-2014)
NIST SP 800-53 SC-13 is pretty clear that it must not just be an approved function, but also FIPS validated cryptography, which is done under FIPS 140-2 and the validated products are listed here: http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-...
I've heard compliance people joke often enough that it's perfectly possible to get a piece of rock FIPS certified. (not that the standards are bad, necessarily, just the thrust of the policies are such that rocks would pass by sheer virtue of not enabling bad actions)
I'm surprised there are no comments yet... I haven't heard of S2n until reading this post, but it sounds like it could potentially replace OpenSSL usage?
Here's the 2 year old thread about S2n https://news.ycombinator.com/item?id=9804349
I think it's relying on libcrypto from openssl, at least that was the case when it came out. E.g. it implements TLS/SSL protocols only, no crypto. Not sure if that's changed and they implemented crypto as well.
From a brief perusal of the source code[0], it still does. It makes this claim on the `README.md` seem rather disingenuous:
> One of the key benefits to s2n is far less code surface, with approximately 6,000 lines of code (compared to OpenSSL’s approximately 500,000 lines).
0: https://github.com/awslabs/s2n/blob/master/crypto/s2n_dhe.h#...
> One of the key benefits to s2n is far less code surface, with approximately 6,000 lines of code (compared to OpenSSL’s approximately 500,000 lines).
0: https://github.com/awslabs/s2n/blob/master/crypto/s2n_dhe.h#...
gnutls is also available.
It's two orders of magnitude less code, but I would be hesitant to say it's more than a linear decrease in vulnerability. Rust (or OCaml in the past) seem like a match made in heaven for solving Heartbleed and Cloudbleed type of problems.
It certainly is possible to write Rust code that references uninitialized memory, and thus serves up whatever was left there on last use. This is one way to get "...bleed" type problems, in which malformed requests trigger responses that sample some stuff lying around on the heap.
http://www.tedunangst.com/flak/post/heartbleed-in-rust
http://www.tedunangst.com/flak/post/heartbleed-in-rust
> identifying memory leaks through fuzz testing.
Do you think that was in the original draft of the release?
Do you think that was in the original draft of the release?
[deleted]
Still an exciting project, especially since the API looks dirt simple to use, but it doesn't live up to the awe I felt when I, at first glance, thought they had given a big middle finger and left OpenSSL behind entirely.