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 marketing!

I think you're being unfair, for they say OpenSSL "contains more than 500,000 lines of code with at least 70,000 of those involved in processing TLS." And the next and last LOC reference is to their s2n, and it's entirely fair to say 6,000 LOC is qualitatively better than "at least 70,000", especially with all the focus, which they cite, on SSL/TLS protocol and implementation bugs.

Still using it for ASN.1 is quite sad, given ASN.1 is where a fair few security bugs have been. If I'm not mistaken, this includes CVE-2015-0286, CVE-2015-0287, CVE-2012-2110, CVE-2009-0590, CVE-2009-0789, and CVE-2006-2937 from the last decade (and more if you go further back). The ciphers are pretty damned solid — the ASN.1 code… not so much. I'd argue that the ASN.1 parsing and the like is one of the areas that sorely needs replacing in OpenSSL, precisely because it has had so many vulnerabilities found in it over the years.

Incidentally, Fabrice Bellard has written a small ASN.1 compiler:

http://bellard.org/ffasn1/

However, he does not want to give it away.

ASN.1 is a rather hairy standard overall, but AFAIK only a part of it is needed for TLS.

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.

The bitcoin piñata recently ended, and they wrote a blog post about it: https://mirage.io/blog/bitcoin-pinata-results

It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?

Sadly, we're not so flush with cash that we can significantly up the prize, which was itself a donation from the user community. It was quite amusing when some kind users donated Bitcoins into the piñata though :-)

We really like the idea of continuing the self-service security bounties, irrespective of their size. One of the nice things about unikernels is that it makes it easy to link in logic like this -- in a conventional OS, it would mean faffing around with kernel modules in order to safely seal the Bitcoins away, whereas here it's just normal high-level language code.

Incidentally, we're working on exposing a C interface to the OCaml TLS stack so that it can be used as a normal shared library as well. The approach is to use the OCaml Ctypes library (which is normally used to bind to C libraries from OCaml), but deploy it in inverted mode. This means that we expose a C ABI from OCaml code instead.

See https://github.com/yallop/ocaml-ctypes-inverted-stubs-exampl... for an example that exposes a C parsing interface to the OCaml XMLM library. The TLS stack isn't much more complex, but is pending us looking into libtls that are easier to expose than OpenSSL's. The s2n release here is thus nice and timely...

Self service security bounties seems like a very smart idea.

Would self-service security bounties enable a distributed bounty ? where each site developer puts a relatively small bounty in his site and his bounty offers him a certain qualification in the eyes of customers , but from the hacker standpoint , if you hacked one , you hacked them all and hence you can collect multiple bounties ?

Isn't that pretty much what we have already with things like openSSL? Find an exploit and suddenly you've exposed everyone. I don't think public bounties would change any of the dynamics around this situation.

With the current system, if you're using an exploit(especially for gain), you're a criminal.Not so when using pinata.

Also , pinata exposes all hacks in public, unlike today.

My point is that I don't believe any of the dynamics would actually change. White hats would still report issues (they're not necessarily doing it for the money) and nefarious types will still trade/sell exploits.

Agreed. I think they offered the bounty with that expectation. A quote form their blog:

"[...] security bounties can be a very effective way to show the presence of vulnerabilities, but they are hopelessly inadequate for showing their absence."

I don't know the answer to that question, but that's about 2/3rds the price of a single billable day for cryptographic pentesting.

> It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?

No amount of prize money can ever really tell you how secure something is. We knew this before we announced it (see background at [1]).

[1] http://amirchaudhry.com/bitcoin-pinata/

A small aside: Haskell has a native TLS implementation as well http://hackage.haskell.org/package/tls

I think the dream is there for many but as other comments have pointed out, getting to the battle tested level of OpenSSL is really really hard.

Github says: C 98.2%, Makefile 1.8% https://github.com/awslabs/s2n

Where is the OCaml source / repo?

edwintorok is comparing s2n with the OCaml-TLS stack. See the links at the end of his comment (and the one below)

https://github.com/mirleft

It's a bizarre comment to be the top response.

"Yo sn2, I'm really happy for you, Imma let you finish but Ocaml had one of the best TLS stacks of all time ... one of the best TLS stacks of all time!"