One thing they don't mention is that it's built against libcrypto. They make it seem like this replaces OpenSSL, but it really only replaces half of it (libssl).
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.
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.
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.
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.
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.
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.
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?
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.
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.
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.