Amazon's New SSL/TLS Implementation In 6,000 Lines of Code 107
bmearns writes: Amazon has announced a new library called "s2n," an open source implementation of SSL/TLS, the cryptographic security protocols behind HTTPS, SSH, SFTP, secure SMTP, and many others. Weighing in at about 6k lines of code, it's just a little more than 1% the size of OpenSSL, which is really good news in terms of security auditing and testing. OpenSSL isn't going away, and Amazon has made clear that they will continue to support it. Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions. Further more, it implements a relatively small subset of SSL/TLS features compared to OpenSSL.
Re: (Score:1)
King Frosty is going to be awfully mad. Two of you, perhaps only miles apart, angry and basement bound and never the twain shall meet. You two could don your favorite superhero outfits and meet in the alley but that seems unlikely. It is unfortunate, it would make an interesting documentary.
Re: (Score:2)
If it implements all the REQUIRED features, then it is TLS.
Free Shipping! (Score:1)
Will they deliver it to me by drone?
Re: (Score:2)
Their implementation of TLS pigeons, s2p, is currently in private beta...
SSH / SFTP are /not/ powered by SSL/TLS (Score:5, Informative)
Re: (Score:1)
Re: (Score:1)
It's not quite as simple as that; although SSH and SSL are distinct protocols, in the actual implementations, there may be some overlap of the crypto libraries. See, for example, http://it.slashdot.org/story/14/04/30/1822209/openssh-no-longer-has-to-depend-on-openssl
Good idea (Score:5, Interesting)
Standards have a notorious habit of becoming bloated with rarely used features that never do get properly tested. Rethinking what is actually useful and needed is great for pruning code and handling the majority of use cases. Sure there will be edge cases it can't handle, but that's the whole point: they're edge cases that most programmers aren't going to need to use.
Re:Good idea (Score:4)
From security perspective, the small code base is an advantage of its own.
Support for limited subset of encryption protocols is also a benefit of its own. E.g. OpenSSL still supports MD5 hashes and would happily use them if one forgets to blacklist them.
Re: (Score:2)
Support for limited subset of encryption protocols is also a benefit of its own. E.g. OpenSSL still supports MD5
Which is quite important, since there are a *lot* of scenarios that still use MD5 (and HMAC-MD5 isn't even broken). So for things that need MD5 hashes even if it's not secure, you can still function, and for things that still use HMAC-MD5, you can still talk *securely*.
Re: (Score:2)
Re: (Score:2)
All the known broken facets of MD5 have zero applicability to HMAC usage scenario. The only part of it that weakens HMAC is that SHA256/SHA512 are more computationally expensive.
If someone knows a weakness in HMAC-MD5, it's hard to imagine it would be related to any of the known broken parts of MD5, and thus HMAC-MD5's chances of being broken might not be so different than any other HMAC use of a hash.
Yes HMAC-SHA2 is the best choice now. Now it's not a good reason to go nuts over things that use HMAC-MD5
Re: (Score:2)
The solution is pretty easy, just use a different Hash, and Apache Commons makes that change a one-liner... but still.. cmoon...
Re: (Score:2)
Sometimes you don't have a choice in an interoperable piece of software. In an aggresive world that tosses away backwards compat in the name of security, you'd either have to toss out a bunch of perfectly ok equipment because you *can't* talk to it anymore, or stick to outdated software to protect the investment, which may have unfixed vulnerabilities because the versions that fix things also dropped support for your needs.
Re: (Score:3)
Agree. It's better to build something rock solid which supports only 80% of all use cases than to end up with something big and bloated that handles every thinkable use case. Yes, the ultimate thing is to have something rock solid that supports everything, but that's an utopia.
Re: (Score:1)
Usable in embedded systems? (Score:1)
Finally (Score:1)
Finally, a quality implementation implemented and backed by a real company. I've had enough of these freelance pet projects get over adopted and used by millions, only to cause some of the worst security breaches in the internet ever!
Compile errors (Score:4, Insightful)
Good, then start debugging. Because I got compile errors on both Linux and MacOS X.
Re: (Score:2)
btw I'm making a
only a few hours spent figuring this thing out/coding, any help is appreciated people.
Do one thing, and do it well. (Score:1)
Re: (Score:2)
In that case, you better try mbed TLS [mbed.org] (former PolarSSL). Has been tested and audited more times than this untested new comer. And it has full support for everything that is needed. mbed TLS makes every new attempt to implement an SSL / TLS library obsolete immediately.
Very much unfinished (Score:5, Informative)
Re: (Score:2)
Yea, its roughly the same as saying I can write windows in one line of assembly ...
Because I can jump to the windows init code ... that was written using millions of lines of code from thousands of other people.
Re: (Score:2)
Though if you think about Amazon's use case for it, this makes sense. Amazon's main business involves running web servers, not clients so much. I could see them writing a server-only TLS library, though they certainly could make use of the client side as well (in Kindle, for instance), so it makes sense that they'd start out with the server side and add the client functionality later.
Re: (Score:2)
NULL cipher (Score:3)
Does it support SSLv2 and weak ciphers like NULL? or is it hardened out of the box?
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
SSLv2 is definitely just "SSL", though.
Everyone knows that... (Score:1)
Seriously though, has s2n been audited independently? Who has been involved in its development (Amazon and...)? You can't wheel out the line count and claim a revolutions has happened.
Re: (Score:2)
Fewer lines means easier to audit once someone gets down to it, though.
Re: (Score:2)
Depends, they could easily have made 6000 Perl one-liners.
Lines of code is really a bad metric. If you have 6000 lines written by a team of bad programmer (which is typical for startups) vs 6,000,000 by a set of really good programmers makes a huge difference.
Re: (Score:1)
Fewer lines means easier to audit once someone gets down to it, though.
Nobody who has ever coded even on a reasonably complex software project would say such a thing.
Just a wrapper around OpenSSL functions (Score:5, Informative)
Summary is misleading at best. A brief inspection of the source code reveals this is still using OpenSSL's crypto functions. So you're not getting 6k lines of source code to replace OpenSSL, as the summary implies. You're getting 6k worth of wrapper code that still uses OpenSSL and needs to be linked against OpenSSL libraries.
Re: (Score:2)
Re: (Score:1)
People have done that before: [conformal.com]
assl was written by Marco Peereboom in order to hide
the awful OpenSSL API. It strives to reuse openssl(1) APIs and provide a
much simpler and sane interface for programmers that are interested in
writing applications that require the SSL/TLS protocol for secure
communications.
This isn't as good as it sounds (Score:5, Insightful)
Ok so firstly it still uses large chunks of OpenSSL (all the crypto stuff) and is still vulnerable to any security holes in that stuff. So its no good on that score.
Also, it disables DHE (which is supposed to be good for ensuring forward secrecy) claiming its a "security risk" (to be fair, maybe there is some security flaw with DHE that I haven't read about yet and that is why its turned off)
Oh and it still supports horridly broken things like RC4, 3DES, SSLv3 and TLS1.0 (all of which contain known unfixable security flaws making them unsuitable going forward)
Re: (Score:2)
maybe there is some security flaw with DHE that I haven't read about yet and that is why its turned off
Logjam [weakdh.org]. TLDR; about 100k hours of CPU time can build a dictionary to crack most session keys in less than 90 seconds for 512bit primes.
Re: (Score:2)
Re: (Score:2)
In corner A:
Or you could just swap to elliptic curve DH and avoid the hassle of staying on top of all that mess.
In corner B:
And it prefers ECDHE over DHE per default, despite all TLS Elliptic Curves being unsafe.
Re: (Score:1)
3DES isn't horridly broken. With the most commonly used keying option, it's vulnerable to a meet-in-the-middle attack, but it still provides 112 bit security. That'll start looking a little lean in the coming years, but it's still a beast to brute force.
On the other hand, RC4, SSLv3, and TLS1.0 are actually broken.
Re: (Score:2)
Re: (Score:3)
Well, here's a good place to start [wikipedia.org]. RC4 has a number of vulnerabilities and while each of them can be mitigated to a certain extent (changing keys, discarding the beginning of streams, etc), the confidence is low that implemented systems will successfully avoid all of them and not open up new vulnerabilities in the process.
Re: (Score:2)
Re: (Score:2)
Apples and oranges (Score:5, Insightful)
... it's just a little more than 1% the size of OpenSSL...Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions....
So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?
Re: (Score:2)
So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?
Possibly misleading, if one doesn't understand the true claims, but definitely useful.
If you're just using OpenSSL for running servers and s2n can provide all of the functions a server needs, and s2n is is 1% of openssl's size, then it's a much, much cheaper target for auditing, and so it's far more feasible to feel secure about it.
If you're doing something different with OpenSSL then the use case
Re: (Score:3)
... it's just a little more than 1% the size of OpenSSL...Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions....
So then, aren't size comparisons between OpenSSL and s2n at best useless, and at worst intentionally misleading?
No, but this particular comparison is. Besides all of the stuff s2n doesn't provide, s2n actually uses OpenSSL's libcrypto to provide the implementations of all of its crypto algorithm. A useful comparison could be made between OpenSSL's TLS layer and s2n, with some caveats listing the TLS features s2n doesn't provide.
Note that none of this means that s2n doesn't have value. If you don't need the other OpenSSL features, it's a lot less code to audit.
Re: (Score:2)
...but this particular comparison is...
Thanks, that is what I meant to imply.
So, in other words.... (Score:1)
6,000 lines of code that DO NOT replace OpenSSL. Only partially replace. A sub-set.
Good Detail Included In Summary (Score:2)
Notably, s2n does not provide all the additional cryptographic functions that OpenSSL provides in libcrypto, it only provides the SSL/TLS functions. Further more, it implements a relatively small subset of SSL/TLS features compared to OpenSSL.
This is the kind of really important detail that is often left out of summaries and winds up making my eye twitch. Thanks OP and/or editors for rising above the common dross.
The bad news (Score:3)
6000 lines of code, that's the good news. The bad news is that it's written in perl and makes heavy use of regular expressions.
simple spot check reveals (Score:1)
https://github.com/awslabs/s2n... [github.com]
contains #include <openssl/...>
Re:Too much code (Score:5, Funny)
Good news, everyone! We have a new code volunteer. Armchair code experts always know best.
Re: (Score:3, Funny)
One line of code, ten thousand characters long, use only internal default variables, would look like an artistic mural done in ascii art and the guy who wrote it would have no idea what it does.
*sigh* I love perl. One of the world first write only languages.
Re: (Score:3)
Huh. Never see ITS TECO [scienceblogs.com], have you?
Re: (Score:2)
And I thought APL [wikipedia.org] was hard to read. (One of my math professors used APL.)
Re: (Score:2)
Re: (Score:2)
Please. APL or go home bitches!
https://en.wikipedia.org/wiki/... [wikipedia.org]
Re: (Score:1)
use Net::SSL;
DONE!
Re:Too many words (Score:2)
30+ words? Bad. Restart if over 10 words.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Yes, that makes perfect sense - because nothing good was ever accomplished in anything other than 1000 lines of easy-to-read C (an oxymoron if ever I've heard it)