Introducing s2n, a New Open-Source TLS Implementation • Hacker News Board

Re: Introducing s2n, a New Open-Source TLS Implementation

#81

Post by cperciva » Tue, Jun 30, 2015, 8:57 PM UTC

halayli wrote: post #76

cperciva wrote: post #38

Earlier quoted context omitted.

I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.

Just because you haven't come across client cert validation requirement, it doesn't mean it's wrong. If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.

If you have a bunch of small services which need to communicate securely, you should be using something like spiped, not TLS.

TLS is the right solution iff you need to communicate with third parties whom you can't securely share code or keys with in advance.

Re: Introducing s2n, a New Open-Source TLS Implementation

#82

Post by cperciva » Tue, Jun 30, 2015, 8:59 PM UTC

makomk wrote: post #77

cperciva wrote: post #75

Earlier quoted context omitted.

reality is that it's really easy to need POSIX APIs Sure. and then you're firmly in autotools land Not at all. If you need the send(2) POSIX system call, what are you going to do if autotools detects that you're on a platform which doesn't have the send(2) system call?

If you're on a platform that doesn't have send(2), you most likely don't have TCP/IP support either and there's no point trying to run an internet server on it. However it is often stuffed away in an oddball platform-specific header and library, and that's where autotools come in - they detect the appropriate flavour of #include statement and the correct library to use.

No - send(2) was often stuffed away in oddball places, and that's why autotools was important 20 years ago; but it isn't any more.

Re: Introducing s2n, a New Open-Source TLS Implementation

#83

Post by halayli » Tue, Jun 30, 2015, 9:01 PM UTC

cperciva wrote: post #38

richm44 wrote: post #8

Note that this library is currently only providing server functionality, and doesn't do certificate validation (in fact it appears to not do any of the X.509 parts of SSL/TLS). It's certainly interesting, but one of the reasons it's so small is that it's missing critical functionality for many use cases.

I think that's kind of the point. If your web server's TLS stack is trying to validate client certificates, you're doing it wrong.

Just because you haven't come across client cert validation requirement, it doesn't mean it's wrong.

If you have a bunch of micro services that need to communicate with each other securely, client cert validation solves a big problem.

Re: Introducing s2n, a New Open-Source TLS Implementation

#84

Post by kibwen » Tue, Jun 30, 2015, 9:04 PM UTC

devy wrote: post #52

So I bet there will be a rust implementation before long :)

There are some Mozilla security folks feeling out the waters as we speak.

Re: Introducing s2n, a New Open-Source TLS Implementation

#85

Post by mback2k » Tue, Jun 30, 2015, 9:17 PM UTC

cbr wrote: post #36

mwcampbell wrote: post #29

I hope libcurl supports this soon.

s2n is server-only

I don't think that this is true. See https://github.com/awslabs/s2n/blob/master/bin/s2nc.c

Re: Introducing s2n, a New Open-Source TLS Implementation

#86

Post by mback2k » Tue, Jun 30, 2015, 9:18 PM UTC

Sounds great. I hope that Windows support without an additional crypto library dependency is added soon, e.g. using Windows CryptoAPI or Windows Cryptography API: Next Generation (CNG).

Re: Introducing s2n, a New Open-Source TLS Implementation

#87

Post by danudey » Tue, Jun 30, 2015, 9:49 PM UTC

wbond wrote: post #51

edwintorok wrote: post #19

If I counted right: OCaml TLS: ~4400 LoC OCaml X509: ~1550 LoC OCaml ASN1: ~1400 LoC OCaml nocrypto: ~5250 LoC Total ~12600 LoC but you get a fully self-contained implementation, having only some crypto code in C and the rest as pure OCaml: https://mirage.io/blog/why-ocaml-tls https://mirage.io/blog/announcing-mirage-25-release

Also note that s2n links with OpenSSL (or LibreSSL, BoringSSL) for the ciphers and ASN.1 functionality. At first I was really surprised/impressed/worried that they managed to pull off an ASN.1 parser in C along with TLS is just 6,000 lines of code. Alas, they did not. So, when they mention the 500,000 lines of OpenSSL, they are probably actually using a good 20,000+ of it for ASN.1 and all of the ciphers. Yay marketi…

On the other hand, the attack area for OpenSSL is the TLS implementation itself, and not the ciphers. Linking against openssl/whatever for ciphers makes more sense than implementing them yourself, and now we can replace OpenSSL's huge, complete TLS implementation with a small, incomplete one that provides just what most people use in a small, auditable package.

Re: Introducing s2n, a New Open-Source TLS Implementation

#88

Post by mzs » Tue, Jun 30, 2015, 9:53 PM UTC

cperciva wrote: post #82

makomk wrote: post #77

Earlier quoted context omitted.

If you're on a platform that doesn't have send(2), you most likely don't have TCP/IP support either and there's no point trying to run an internet server on it. However it is often stuffed away in an oddball platform-specific header and library, and that's where autotools come in - they detect the appropriate flavour of #include statement and the correct library to use.

No - send(2) was often stuffed away in oddball places, and that's why autotools was important 20 years ago; but it isn't any more.

Sadly I think you still need -lnsl -lsocket on solaris :(

Re: Introducing s2n, a New Open-Source TLS Implementation

#89

Post by cperciva » Tue, Jun 30, 2015, 10:49 PM UTC

mzs wrote: post #88

cperciva wrote: post #82

Earlier quoted context omitted.

No - send(2) was often stuffed away in oddball places, and that's why autotools was important 20 years ago; but it isn't any more.

Sadly I think you still need -lnsl -lsocket on solaris :(

Touché! (I think only -lsocket is required for send(2) though -- unless I'm misremembering, -lnsl is just for DNS lookups.)

Still, there's relatively few portability issues these days:

1. Some platforms don't define MSG_NOSIGNAL. (You can work around this via setsockopt.)

2. Some platforms don't define CLOCK_REALTIME. (On platforms which don't provide that, you should be able to use gettimeofday.)

3. Some platforms don't understand -lrt or -lxnet. (This one is awkward since some platforms require those. You have to either taste the compiler or detect the OS.)

4. Solaris needs -lsocket and/or -lnsl for networking related functions. (Either detect Solaris or decide that it's rare enough that you don't really care about supporting it. In spiped I opt for a note in BUILDING telling people how to work around the Solaris standards-compliance bug.)

Compare this to the situation when autotools originated, and we're about 99% better.

Re: Introducing s2n, a New Open-Source TLS Implementation

#90

Post by cperciva » Tue, Jun 30, 2015, 10:52 PM UTC

aaronbrethorst wrote: post #70

Tepix wrote: post #63

Earlier quoted context omitted.

Source?

I think cperciva's opinion is a sufficiently valid source on this sort of issue, which is probably why you're being down voted.

Thank you for the vote of confidence, but you're wrong. The question of "real world usage of TLS" is one where I would immediately defer to tptacek without question... and you've been around long enough to know that's something I don't do very often.