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

← Back to Stories (view on slashdot.org)

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

Posted by Soulskill on Wednesday July 1, 2015 @12:22AM from the simplify-condense-and-shorten dept.

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.

107 comments

Min score:

Reason:

Sort:

One line comment by Anonymous Coward · 2015-07-01 00:24 · Score: 0

I'm first royal poster!
1. Re:One line comment by KGIII · 2015-07-01 16:30 · 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."
Not tls by Anonymous Coward · 2015-07-01 00:25 · Score: 0

Then this is not tls.
>Further more, it implements a relatively small subset of SSL/TLS features compared to OpenSSL.
1. Re:Not tls by Pseudonym · 2015-07-01 18:33 · 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});
Too much code by Anonymous Coward · 2015-07-01 00:27 · Score: -1

Why does it take 6k lines of code to imÃ¥lement this? Someone needs to rethink the standard. If it's not doable in 1000 lines of easy to read C, start over again.
1. Re:Too much code by halivar · 2015-07-01 00:30 · Score: 5, Funny
  
  Good news, everyone! We have a new code volunteer. Armchair code experts always know best.
2. Re:Too much code by Anonymous Coward · 2015-07-01 00:40 · Score: -1
  
  Pah, a perl developer would do it in 1 line of code.
3. Re:Too much code by Anonymous Coward · 2015-07-01 01:08 · Score: 0
  
  You can't do much in 1,000 lines.
4. Re: Too much code by Anonymous Coward · 2015-07-01 01:37 · Score: 0
  
  You can if you remove the line breaks :p
5. Re:Too much code by Anonymous Coward · 2015-07-01 01:37 · 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.
6. Re:Too much code by mellon · 2015-07-01 02:02 · Score: 2
  
  Huh. Never see ITS TECO, have you?
7. Re:Too much code by PRMan · 2015-07-01 02:28 · 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...
8. Re:Too much code by UnderCoverPenguin · 2015-07-01 05:20 · 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
9. Re:Too much code by OhSoLaMeow · 2015-07-01 05:37 · 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.
10. Re:Too much code by the_B0fh · 2015-07-01 06:23 · Score: 1
  
  Please. APL or go home bitches!
  https://en.wikipedia.org/wiki/...
11. Re:Too much code by Anonymous Coward · 2015-07-01 09:04 · Score: 0
  
  Because it has many features. All the encryption algorithms alone are probably >1000 lines long. Would you trust a standard only focussing on a single encryption algorithm.
  Typically, when we see standards like this they also try to promote a proprietary algorithm (that often turns out the be, sometime trivially, insecure), but of course this is not a given.
12. Re:Too much code by PhunkySchtuff · 2015-07-01 10:41 · 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)
  
  --
  Specialist Mac support for creative pros, Melbourne
13. Re:Too much code by Anonymous Coward · 2015-07-01 10:47 · Score: 1
  
  use Net::SSL;
  DONE!
14. Re:Too much code by Anonymous Coward · 2015-07-01 10:51 · Score: 0
  
  It greatly depends on the language.
  1000 lines in Ruby, Python, Elixir, etc, can do a fuckton more than C, C++, C# and especially Java.
  I have seen < 5000 line Rails apps that match features with 40,000 lines of the shit known as PHP and 80000+ lines of Java.
15. Re:Too much code by Anonymous Coward · 2015-07-01 11:50 · Score: 0
  
  IOC?
  You mean the nonsense that Java architecture astronauts are in love with by has no value in sane languages.
  That IOC?
16. Re:Too much code by Gazzonyx · 2015-07-01 16:52 · 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.
17. Re:Too much code by Anonymous Coward · 2015-07-01 23:14 · Score: 0
  
  There's even a machine instruction for an AES round. Don't tell me that you need a thousand lines to implement AES...
Free Shipping! by Anonymous Coward · 2015-07-01 00:27 · Score: 1

Will they deliver it to me by drone?
1. Re:Free Shipping! by Sneeka2 · 2015-07-01 00:30 · Score: 1
  
  Their implementation of TLS pigeons, s2p, is currently in private beta...
  
  --
  Bitten Apples are still better than dirty Windows...
SSH / SFTP are /not/ powered by SSL/TLS by TerraFrost · 2015-07-01 00:32 · 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 · 2015-07-01 01:09 · Score: 1
  
  Your mom uses SSH
2. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · 2015-07-01 01:18 · 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
3. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · 2015-07-01 02:47 · Score: -1
  
  You are a cow. A cow says moo. MOOOOOOOOO! MOOOOOOOO cow moooooooo! MOOOOO says the cow. YOU COW!!
4. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · 2015-07-01 03:22 · Score: 0
  
  You mom has the TLS STDs while my mom is still healthy.
5. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · 2015-07-01 03:44 · Score: 0
  
  FTPS uses TLS/SSL ......but only not for the control channel (or at least the login phase)
  SFTP is over SSH
  When talking about it, I mix those two up all the time.....Where do I put that S again?
6. Re:SSH / SFTP are /not/ powered by SSL/TLS by Anonymous Coward · 2015-07-01 07:15 · Score: 0
  
  Yes it is as simple as that. Just because one implementation of SSH shares some code with one implementation of SSL does not mean that SSH has anything to do with the SSL protocol.
Good idea by msobkow · 2015-07-01 00:33 · 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 · 2015-07-01 00:51 · 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 · 2015-07-01 00:58 · 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 · 2015-07-01 01:02 · 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 · 2015-07-01 01:46 · 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 · 2015-07-01 02:23 · 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 Anonymous Coward · 2015-07-01 03:41 · Score: 0
  
  No, the ultimate thing is to have both.
  This speaks against re-using the one and same library when possible. There is a need for multiple overlapping libraries.
  There is a need for both the large bloated and buggy library that handles all use cases and a small footprint library that works on embedded devices that if you are lucky supports C99 to some extent and sometimes have more than 64k memory.
  In most cases the small library can have the functionality that covers most use cases and thus also be used for all applications that doesn't need the large bloated thing.
7. Re:Good idea by Junta · 2015-07-01 05:34 · 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.
8. Re:Good idea by Junta · 2015-07-01 05:37 · 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.
9. Re:Good idea by Anonymous Coward · 2015-07-01 07:18 · Score: 0
  
  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.
  Yes, but there's no need for fanboys to jeer at other stores that decide they do still want to support 3.11.
10. Re:Good idea by Anonymous Coward · 2015-07-01 07:20 · Score: 0
  
  In most cases the small library can have the functionality that covers most use cases and thus also be used for all applications that doesn't need the large bloated thing.
  But it would be better still if the "large bloated" thing was rock solid, so that applications that do need all the functionality don't fall apart every five minutes.
11. Re: Good idea by Anonymous Coward · 2015-07-01 07:59 · Score: 0
  
  https://github.com/awslabs/s2n/blob/master/crypto/s2n_hmac.c
Why no use libressl by Anonymous Coward · 2015-07-01 00:33 · Score: 0

eh ?
1. Re:Why no use libressl by behrooz0az · 2015-07-01 00:56 · 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)
Usable in embedded systems? by responsibleusername · 2015-07-01 00:41 · 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.
Probably possible to beat still by Anonymous Coward · 2015-07-01 00:45 · Score: 0

Without knowing how much Amazon have left out of their implementation I'd guess it's possible to still slash that by a factor of 2 or 3. I started yet another TLS implementation for a current project about two weeks ago after reading comments like this one: http://security.stackexchange.com/a/3213. I don't expect to need more than 2klOC at this point.
1. Re:Probably possible to beat still by Anonymous Coward · 2015-07-01 05:50 · Score: 0
  
  That is what I thought.
  The OpenBSD project has libtls.
  Quoting tls_init(3)
  "The tls API first appeared in OpenBSD 5.6 as a response to the
  unnecessary challenges other APIs present in order to use them safely."
  and it has
  lets see here
  cd /usr/src/lib
  find libtls -type f | xargs cat | wc -l
  2240
  6000 Loc is three times bigger than it needs to be.
Finally by Anonymous Coward · 2015-07-01 00:46 · 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!
1. Re: Finally by Anonymous Coward · 2015-07-01 00:54 · Score: 0
  
  Yeah, OpenSSH is a real piece of shit, eh?
Compile errors by Aethedor · 2015-07-01 00:46 · 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 · 2015-07-01 04:46 · 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)
2. Re:Compile errors by Anonymous Coward · 2015-07-02 00:45 · Score: 0
  
  Fails with BSD make (it uses gnu-isms) and you can't point GNU make at it since the Makefile calls make instead of $(MAKE)
  (/usr/bin/make is BSD make, the GNU make is named gmake)
  After that's fixed,
  s2n_random.c: In function 's2n_init': s2n_random.c:213: error: 'ENGINE_FLAGS_NO_REGISTER_ALL' undeclared (first use in this function) s2n_random.c:213: error: (Each undeclared identifier is reported only once s2n_random.c:213: error: for each function it appears in.)
  I have /no/ idea where that #define is. OpenSSL headers, I guess? Why is the thing including OpenSSL headers anyway?
  (FreeBSD 9.3)
Do one thing, and do it well. by hilather · 2015-07-01 01:00 · Score: 0

I hope this takes over as the defacto standard for HTTPS. I'm tired of constantly seeing SSL and OpenSSL vulnerabilities.
1. Re:Do one thing, and do it well. by Anonymous Coward · 2015-07-01 01:28 · Score: 0
  
  There have been a few big ones in the news lately. But I have become kind of glad to see it. At least they are being patched instead going un-found or worse...only known to malicious actors.
2. Re:Do one thing, and do it well. by Aethedor · 2015-07-01 03:13 · 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.
3. Re:Do one thing, and do it well. by Anonymous Coward · 2015-07-01 03:34 · Score: 0
  
  Yeah sure. What could possibly go wrong when something is backed by a large UK Plc ?
  Hint: Belgacom.
blogs.aws.amazon.com uses 3DES by Anonymous Coward · 2015-07-01 01:00 · Score: 0

Ironically the https version of blogs.aws.amazon.com uses the relatively weak 3DES.
1. Re: blogs.aws.amazon.com uses 3DES by Anonymous Coward · 2015-07-01 02:11 · Score: 0
  
  You mean relative to the NSA back doored AES?
  I can do hyperbolic too. 3DES is still secure
2. Re:blogs.aws.amazon.com uses 3DES by Anonymous Coward · 2015-07-01 02:23 · Score: 0
  
  Ironically* you are a moron that does not know what he's talking about. 3DES is absolutely fine and the least likely of all symmetric cyphers to have been backdoored.
  * Yes, I know there's no actual irony involved here...
3. Re:blogs.aws.amazon.com uses 3DES by Anonymous Coward · 2015-07-01 03:36 · Score: 0
  
  You are a clueless idiot. You confuse DES and 3DES.
mod D0wn by Anonymous Coward · 2015-07-01 01:02 · Score: -1

stu4iNd. To the is the worst off
Very much unfinished by Lumpio- · 2015-07-01 01:03 · 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 · 2015-07-01 01:50 · 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 · 2015-07-01 09:38 · 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- · 2015-07-01 09:41 · Score: 1
  
  My point was that it's not that useful to compare it to other libraries unless there's feature parity.
Re:Too many words by mwvdlee · 2015-07-01 01:05 · Score: 1

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

--
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
NULL cipher by snsh · 2015-07-01 01:06 · 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 · 2015-07-01 01:48 · 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 · 2015-07-01 05:49 · 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.
  
  --
  Support my political activism on Patreon.
3. Re:NULL cipher by Anonymous Coward · 2015-07-01 07:24 · Score: 0
  
  The term "SSL" almost always refers to TLS as well.
4. Re:NULL cipher by Anonymous Coward · 2015-07-01 08:47 · Score: 1
  
  SSLv2 is definitely just "SSL", though.
5. Re:NULL cipher by Anonymous Coward · 2015-07-01 10:50 · Score: 0
  
  Null cipher is important from a testing perspective to ascertain how much overhead you have in the system from the encryption itself. Shouldn't be turned on by default though.
Everyone knows that... by bazmail · 2015-07-01 01:07 · Score: 0

... fewer lines means better software right? Why not write it in Python and get it down to one line. That would clearly be the best implementation.

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.
1. Re:Everyone knows that... by Shados · 2015-07-01 01:15 · Score: 1
  
  Fewer lines means easier to audit once someone gets down to it, though.
2. Re:Everyone knows that... by guruevi · 2015-07-01 01:24 · 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
3. Re:Everyone knows that... by bazmail · 2015-07-01 01:44 · Score: 0
  
  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 by punman · 2015-07-01 01:19 · 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 · 2015-07-01 01:33 · 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 · 2015-07-02 01:13 · 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.
This isn't as good as it sounds by jonwil · 2015-07-01 01:23 · 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 · 2015-07-01 01:40 · 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 Anonymous Coward · 2015-07-01 01:49 · Score: 0
  
  Right, but, the correct fix is to just use longer primes (1024 is probably fine unless your adversary is a world government, 2048 is safe). Not disable the entirety of DHE.
3. Re:This isn't as good as it sounds by Anonymous Coward · 2015-07-01 01:55 · Score: 0
  
  Why is why you tell all 1024bit primes to go take a flying fuck. In time you raise that to 2048bit DH prime group generation.
4. Re:This isn't as good as it sounds by Anonymous Coward · 2015-07-01 02:25 · Score: 0
  
  Oh and it still supports horridly broken things like RC4, 3DES, SSLv3 and TLS1.0
  TLS1.0 is broken?
  Could you elaborate?
  Certain ciphers, like rc4 with TLS1.0 are broken, but TLS1.0 in general?
5. Re:This isn't as good as it sounds by chihowa · 2015-07-01 02:27 · Score: 0
  
  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.
  
  --
  If you want a vision of the future, imagine a youtube comments section scrolling - forever.
6. Re:This isn't as good as it sounds by complete+loony · 2015-07-01 02:34 · 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.
7. Re:This isn't as good as it sounds by Anonymous Coward · 2015-07-01 02:41 · Score: 0
  
  Which isn't a flaw with DH, but a problem of choosing too short of a prime. Anytime you choose a short key you're going to run into vulnerabilities.
8. Re:This isn't as good as it sounds by Meneth · 2015-07-01 04:20 · Score: 1
  
  And it prefers ECDHE over DHE per default, despite all TLS Elliptic Curves being unsafe.
9. Re:This isn't as good as it sounds by bluefoxlucid · 2015-07-01 05:51 · Score: 1
  
  Someone explain how RC4 is broken. I thought the issues were highly sensitive to environment, notably weak IVs.
  
  --
  Support my political activism on Patreon.
10. Re:This isn't as good as it sounds by bluefoxlucid · 2015-07-01 05:52 · 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.
  
  --
  Support my political activism on Patreon.
11. Re:This isn't as good as it sounds by chihowa · 2015-07-01 08:53 · 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.
12. Re:This isn't as good as it sounds by Anonymous Coward · 2015-07-01 09:54 · Score: 0
  
  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.
  Logjam is a protocol attack that tricks the victim(s) into using small-ish prime (i.e. 512-bit) for the Diffie-Hellman key Exchange (DHE). Their demonstration which required they were able to do a large amount of pre-computations (100k hours of CPU time ==> 11 years-worth if using a single CPU) which allowed them to crack individual session keys in less than 90 seconds.
  Since browsers, servers, and libraries should be patched to the protocol vulnerability, back in May 2015, and servers are encouraged to use be (re-)configured to use 1024-bit or larger Diffie-Hellman groups. Entirely disabling DHE is not necessary, and to conclude that DHE is broken is to misunderstand the situation.
  Likewise, while Triple-DES is largely a legacy symmetric encryption algorithm these days, as far as I know, there has been no indication that is is weaker than its perceived strength of 112-bits keys (due to a meet in the middle attack). No one is encouraged to deploy anything new with 3DES support, existing usage is not considered insecure. AFAIK it is still acceptable to US NIST for secure non-classified government usage, and with PCI (online US credit card gateway requirements).
13. Re:This isn't as good as it sounds by bluefoxlucid · 2015-07-02 01:07 · 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.
  
  --
  Support my political activism on Patreon.
Apples and oranges by QuietLagoon · 2015-07-01 01:33 · 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 · 2015-07-01 01:50 · 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 · 2015-07-01 02:06 · 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 · 2015-07-01 02:31 · Score: 1
  
  ...but this particular comparison is...
  Thanks, that is what I meant to imply.
So, in other words.... by gerald.edward.butler · 2015-07-01 02:04 · Score: 1

6,000 lines of code that DO NOT replace OpenSSL. Only partially replace. A sub-set.
Good Detail Included In Summary by Bob9113 · 2015-07-01 03:18 · 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.

--
Stop-Prism.org: Opt Out of Surveillance
The bad news by backslashdot · 2015-07-01 03:33 · 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.
1. Re:The bad news by Anonymous Coward · 2015-07-01 17:27 · Score: 0
  
  Is it possible to write perl scripts without regular expressions?
LibreSSL by Anonymous Coward · 2015-07-01 04:49 · Score: 0

How does Amazon's implementation compare to LibreSSL? http://www.libressl.org
6K lines of code? by Anonymous Coward · 2015-07-01 04:57 · Score: 0

If you cannot implement all of these in 6-10KLOC then you are an idiot! I wouldn't hire you!
simple spot check reveals by technosaurus · 2015-07-01 09:51 · Score: 1

its not much of anything:
https://github.com/awslabs/s2n...
contains #include <openssl/...>
Given SSLv3's deprecated in RFC7568... by Anonymous Coward · 2015-07-01 17:13 · Score: 0

...maybe we need to replace OpenSSL (and now s2n) with OpenTLS and be rid of all the insecure SSL mess.
So, SSLv3 That Has Just Been Deprecated? by Anonymous Coward · 2015-07-03 08:14 · Score: 0

Nicely done, Amazon!
You just implemented SSLv3 that has been deprecated and appeared on divided-by-decimal one day prior to your announcement.
http://tech.slashdot.org/story/15/06/30/1457204/rfc-7568-deprecates-sslv3-as-insecure