7 ms·

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 se

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/why-ocaml-tls https://mirage.io/blog/announcing-mirage-25-release https://mirage.io/blog/announcing-mirage-25-release

reycharles 11y ago
The bitcoin piñata recently ended, and they wrote a blog post about it: https://mirage.io/blog/bitcoin-pinata-results https://mirage.io/blog/bitcoin-pinata-results
- minthd 11y ago
  It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?
  - LukeHoersten 11y ago
    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."
  - avsm 11y ago
    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-example 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...
    - minthd 11y ago
      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 ?
      - amirmc 11y ago
        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.
        minthd 11y ago
        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.
        amirmc 11y ago
        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.
  - tptacek 11y ago
    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.
  - amirmc 11y ago
    > 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/ http://amirchaudhry.com/bitcoin-pinata/
LukeHoersten 11y ago
A small aside: Haskell has a native TLS implementation as well http://hackage.haskell.org/package/tls 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.
wbond 11y ago
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!
- hga 11y ago
  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.
- danudey 11y ago
  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.
- gsnedders 11y ago
  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.
  - userbinator 11y ago
    Incidentally, Fabrice Bellard has written a small ASN.1 compiler: http://bellard.org/ffasn1/ 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.
frik 11y ago
Github says: C 98.2%, Makefile 1.8% https://github.com/awslabs/s2n https://github.com/awslabs/s2n Where is the OCaml source / repo?
- amirmc 11y ago
  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 https://github.com/mirleft
  - bradleyjg 11y ago
    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!"
    - justizin 11y ago
      "Have you heard of s2n?" "I love s2n!" [edit: oh, c'mon with the downvotes, it was a follow-up kanye ref about beck!]

reycharles 11y ago

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

minthd 11y ago
It's interesting, but isn't 10BTC($2500) prize too low to tell us anything about how secure is this ?
- LukeHoersten 11y ago
  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."
- avsm 11y ago
  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-example 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...
  - minthd 11y ago
    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 ?
    - amirmc 11y ago
      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.
      - minthd 11y ago
        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.
        amirmc 11y ago
        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.
- tptacek 11y ago
  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.
- amirmc 11y ago
  > 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/ http://amirchaudhry.com/bitcoin-pinata/

LukeHoersten 11y ago

A small aside: Haskell has a native TLS implementation as well http://hackage.haskell.org/package/tls 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.

wbond 11y ago

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!

hga 11y ago
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.
danudey 11y ago
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.
gsnedders 11y ago
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.
- userbinator 11y ago
  Incidentally, Fabrice Bellard has written a small ASN.1 compiler: http://bellard.org/ffasn1/ 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.

frik 11y ago

Github says: C 98.2%, Makefile 1.8% https://github.com/awslabs/s2n https://github.com/awslabs/s2n Where is the OCaml source / repo?

amirmc 11y ago
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 https://github.com/mirleft
- bradleyjg 11y ago
  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!"
  - justizin 11y ago
    "Have you heard of s2n?" "I love s2n!" [edit: oh, c'mon with the downvotes, it was a follow-up kanye ref about beck!]