Slashdot Mirror


Amazon's New SSL/TLS Implementation In 6,000 Lines of Code

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.

61 of 107 comments (clear)

  1. Free Shipping! by Anonymous Coward · · Score: 1

    Will they deliver it to me by drone?

    1. Re:Free Shipping! by Sneeka2 · · Score: 1

      Their implementation of TLS pigeons, s2p, is currently in private beta...

      --
      Bitten Apples are still better than dirty Windows...
  2. Re:Too much code by halivar · · Score: 5, Funny

    Good news, everyone! We have a new code volunteer. Armchair code experts always know best.

  3. SSH / SFTP are /not/ powered by SSL/TLS by TerraFrost · · Score: 5, Informative

    The story summary got it wrong - SSH uses it's own distinct protocol to establish an encrypted connection and SFTP is a subsystem of SSH.

    1. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · · Score: 1

      Your mom uses SSH

    2. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · · 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

  4. Good idea by msobkow · · Score: 4, 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.

    --
    I do not fail; I succeed at finding out what does not work.
    1. Re:Good idea by ThePhilips · · Score: 3

      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.

      --
      All hope abandon ye who enter here.
    2. Re:Good idea by Aethedor · · Score: 2

      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.

      --
      It doesn't have to be like this. All we need to do is make sure we keep talking.
    3. Re:Good idea by Junta · · Score: 1

      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*.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    4. Re:Good idea by jandrese · · Score: 1

      Maybe you can talk securely. Nobody has publicly announced any vulnerabilities in HMAC-MD5 yet, but that MD5 piece hanging off of there makes me nervous. If Amazon is willing to say that they no longer support Windows 3.11 for Workgroups users buying products from the Amazon store, it is their call. They have to weigh the loss of customers over discovering later that some weird long forgotten part of their OpenSSL implementation gave the keys to the kingdom over to the hackers.

      --

      I read the internet for the articles.
    5. Re:Good idea by s122604 · · Score: 1

      Somebody needs to tell a certain company that does third party security validation that. MD5 hashes have use in things that have nothing to do with security, and they constantly get flagged.
      The solution is pretty easy, just use a different Hash, and Apache Commons makes that change a one-liner... but still.. cmoon...

    6. Re:Good idea by Junta · · Score: 1

      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 today.

      --
      XML is like violence. If it doesn't solve the problem, use more.
    7. Re:Good idea by Junta · · Score: 1

      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.

      --
      XML is like violence. If it doesn't solve the problem, use more.
  5. Usable in embedded systems? by responsibleusername · · Score: 1

    Seems like it might be useful in embedded systems, but I don't see any mention of that in any of the articles.

  6. Finally by Anonymous Coward · · 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!

  7. Compile errors by Aethedor · · Score: 3, Insightful

    ... which is really good news in terms of security auditing and testing.

    Good, then start debugging. Because I got compile errors on both Linux and MacOS X.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
    1. Re:Compile errors by behrooz0az · · Score: 2

      Same here, but in some weird way the '.so' file is there and a header file which has a 'duplicate function' in it named 's2n_shutdown', maybe they wanted to make sure it shuts down.
      btw I'm making a .net wrapper at https://github.com/Behrooz-Amo...
      only a few hours spent figuring this thing out/coding, any help is appreciated people.

      --
      Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
  8. Re:Why no use libressl by behrooz0az · · Score: 1

    It does, from README file:br/ s2n has been structured so that different encryption libraries may be used. Today s2n supports OpenSSL, LibreSSL, BoringSSL, and the Apple Common Crypto framework to perform the underlying cryptographic operations.

    --
    Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
  9. Very much unfinished by Lumpio- · · Score: 5, Informative

    Did anybody notice that it doesn't, for example, do client mode at all yet? Or it does, but it doesn't implement cert validation at all which makes it useless as a client at the moment and therefore client mode is disabled. That along with delegating all the actual crypto to other libraries means the entire thing doesn't actually *do* much. No wonder it's only 6kLOC.

    1. Re:Very much unfinished by BitZtream · · Score: 1

      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.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    2. Re:Very much unfinished by hawaiian717 · · Score: 1

      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.

      --
      End of Line.
    3. Re:Very much unfinished by Lumpio- · · Score: 1

      My point was that it's not that useful to compare it to other libraries unless there's feature parity.

  10. Re:Too many words by mwvdlee · · Score: 1

    30+ words? Bad. Restart if over 10 words.

    --
    Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
  11. NULL cipher by snsh · · Score: 2

    Does it support SSLv2 and weak ciphers like NULL? or is it hardened out of the box?

    1. Re:NULL cipher by jandrese · · Score: 1

      The TFA mentioned that it only supports a tiny subset of the functionality that OpenSSL supports. I'm reasonably certain that they didn't include the old and broken stuff in their rewrite.

      --

      I read the internet for the articles.
    2. Re:NULL cipher by bluefoxlucid · · Score: 1

      Uh, it shouldn't support SSL at all. SSL is an insecure protocol which, by modern web standards, should not be used ever; TLS is the current protocol.

    3. Re:NULL cipher by Anonymous Coward · · Score: 1

      SSLv2 is definitely just "SSL", though.

  12. Re:Everyone knows that... by Shados · · Score: 1

    Fewer lines means easier to audit once someone gets down to it, though.

  13. Just a wrapper around OpenSSL functions by punman · · 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.

    1. Re:Just a wrapper around OpenSSL functions by Bengie · · Score: 1

      It looks like it's a wrapping library that makes it easier to use OpenSSL more safely by limiting which features you can use and how they're used.

    2. Re:Just a wrapper around OpenSSL functions by gustygolf · · Score: 1

      People have done that before:

      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.

      --
      "Slow Down Cowboy! It's been 58 minutes since you last successfully posted a comment" -- slashdot, driving users away.
  14. This isn't as good as it sounds by jonwil · · Score: 4, 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)

    1. Re:This isn't as good as it sounds by complete+loony · · Score: 1

      maybe there is some security flaw with DHE that I haven't read about yet and that is why its turned off

      Logjam. TLDR; about 100k hours of CPU time can build a dictionary to crack most session keys in less than 90 seconds for 512bit primes.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    2. Re:This isn't as good as it sounds by complete+loony · · Score: 1

      Another fix is to generate more good primes to use. Instead of hard coding them in the source. Or you could just swap to elliptic curve DH and avoid the hassle of staying on top of all that mess.

      --
      09F91102 no, 455FE104 nope, F190A1E8 uh-uh, 7A5F8A09 that's not it, C87294CE no. Ah! 452F6E403CDF10714E41DFAA257D313F.
    3. Re:This isn't as good as it sounds by Meneth · · Score: 1

      And it prefers ECDHE over DHE per default, despite all TLS Elliptic Curves being unsafe.

    4. Re:This isn't as good as it sounds by bluefoxlucid · · Score: 1

      Someone explain how RC4 is broken. I thought the issues were highly sensitive to environment, notably weak IVs.

    5. Re:This isn't as good as it sounds by bluefoxlucid · · Score: 1

      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.

    6. Re:This isn't as good as it sounds by chihowa · · Score: 2

      Well, here's a good place to start. 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.

      --
      If you want a vision of the future, imagine a youtube comments section scrolling - forever.
    7. Re:This isn't as good as it sounds by bluefoxlucid · · Score: 1

      Ah, okay. It has actual weaknesses. I had for a long time only heard of protocol weaknesses: RC4 implemented without HMAC, with the key and IV scheduled a certain way, appending a nonce instead of hashing it, has many weaknesses; such statements are ridiculous, because everything implemented poorly has weaknesses (this is why we have key exchange protocols, and VPNs which generate a random RSA key per session and are thus completely insecure). It looks like RSA has some key recovery weaknesses you can't mitigate by a proper protocol.

  15. Re:Everyone knows that... by guruevi · · Score: 1

    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.

    --
    Custom electronics and digital signage for your business: www.evcircuits.com
  16. Apples and oranges by QuietLagoon · · Score: 4, 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?

    1. Re:Apples and oranges by bill_mcgonigle · · Score: 1

      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 probably doesn't apply.

      It may be that a machine analysis of the OpenSSL codebase, starting with the function calls from, say, mod_ssl, could produce a useful graph of the OpenSSL code that's actually in use by typical servers. I'm not personally aware of such an effort, but it seems obvious enough that probably somebody has done it.

      --
      My God, it's Full of Source!
      OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    2. Re:Apples and oranges by swillden · · Score: 2

      ... 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.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    3. Re:Apples and oranges by QuietLagoon · · Score: 1

      ...but this particular comparison is...

      Thanks, that is what I meant to imply.

  17. Re:Too much code by Anonymous Coward · · 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.

  18. Re:Too much code by mellon · · Score: 2

    Huh. Never see ITS TECO, have you?

  19. So, in other words.... by gerald.edward.butler · · Score: 1

    6,000 lines of code that DO NOT replace OpenSSL. Only partially replace. A sub-set.

  20. Re:Too much code by PRMan · · Score: 1

    But then how are you going to do Inversion of Control (TM)?

    --
    Peter predicted that you would "deliberately forget" creation 2000 years ago...
  21. Re:Do one thing, and do it well. by Aethedor · · Score: 1

    In that case, you better try mbed TLS (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.

    --
    It doesn't have to be like this. All we need to do is make sure we keep talking.
  22. Good Detail Included In Summary by Bob9113 · · Score: 1

    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.

  23. The bad news by backslashdot · · Score: 2

    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.

  24. Re:Too much code by UnderCoverPenguin · · Score: 1

    And I thought APL was hard to read. (One of my math professors used APL.)

    --
    Don't try to out wierd me, three-eyes. I get stranger things than you, free with my breakfast cereal. --Zaphod Beeblebr
  25. Re:Too much code by OhSoLaMeow · · Score: 1

    In a past life one of my co-workers wrote an APL interpreter. It put the terminal into graphics mode to generate the funky APL character set.

    --
    They can take my LifeAlert pendant when they pry it from my cold dead fingers.
  26. Re:Too much code by the_B0fh · · Score: 1

    Please. APL or go home bitches!

    https://en.wikipedia.org/wiki/...

  27. simple spot check reveals by technosaurus · · Score: 1

    its not much of anything:
    https://github.com/awslabs/s2n...
    contains #include <openssl/...>

  28. Re:Too much code by PhunkySchtuff · · Score: 1

    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)

  29. Re:Too much code by Anonymous Coward · · Score: 1

    use Net::SSL;

    DONE!

  30. Re:One line comment by KGIII · · 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.

    --
    "So long and thanks for all the fish."
  31. Re:Too much code by Gazzonyx · · Score: 1

    That is generally what happens when you compare line counts for code on top of a framework against stuff written in other languages.

    --

    If I mod you up, it doesn't necessarily mean I agree with what you've said, sorry.

  32. Re:Not tls by Pseudonym · · Score: 1

    If it implements all the REQUIRED features, then it is TLS.

    --
    sub f{($f)=@_;print"$f(q{$f});";}f(q{sub f{($f)=@_;print"$f(q{$f});";}f});