Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Transport Layer Security in pure OCaml

openmirage.org

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Introducing Transport Layer Security in pure OCaml

#11

Post by edwintorok »

pdpi wrote: post #7
hoggle wrote: post #4

Are we finally approaching consensus in the field of systems programming that security is more important than performance (thanks to heartbleed)? Or put differently: have we reached the point where computers are fast enough so that we can move on and sacrifice some of those abundant MIPS and extra RAM for much improved clarity in our critical infrastructure code? OCaml could actually be a great choice for maintaining…

For the sake of moving things forward: every time we have this discussion, someone always points out that functional languages would make it easier to get correct behaviour from a crypto library, and someone always replies that garbage collection opens you up to side-channel (timing, in this case) attacks.

The actual crypto primitives are still implemented in C, do those timing attack apply to the high-level part implemented in OCaml too?

Re: Introducing Transport Layer Security in pure OCaml

#12

Post by olifante »

Security is too damn important to use languages that are insecure by default and that require rigorous discipline and extensive auditing, such as C and C++. The world needs to move its entire crypto and networking layer to functional languages focusing on immutability, thereby immensely reducing the surface of attack.

Re: Introducing Transport Layer Security in pure OCaml

#13

Post by duaneb »

hoggle wrote: post #4

Are we finally approaching consensus in the field of systems programming that security is more important than performance (thanks to heartbleed)? Or put differently: have we reached the point where computers are fast enough so that we can move on and sacrifice some of those abundant MIPS and extra RAM for much improved clarity in our critical infrastructure code? OCaml could actually be a great choice for maintaining…

> OCaml could actually be a great choice for maintaining a solid TLS layer.

Maybe; it uses GC and it's difficult to embed. I would much prefer something that compiles without a runtime (or with a minimal one for resource allocation).

Re: Introducing Transport Layer Security in pure OCaml

#14

Post by jude- »

olifante wrote: post #12

Security is too damn important to use languages that are insecure by default and that require rigorous discipline and extensive auditing, such as C and C++. The world needs to move its entire crypto and networking layer to functional languages focusing on immutability, thereby immensely reducing the surface of attack.

Secure implementations require more than formal, logical correctness. They must also not leak information to adversaries--i.e. the must be free of side-channels. Unfortunately, ensuring this usually requires the developers to be aware of the low-level behavior of the underlying architecture, which is difficult in functional languages since unlike C, they abstract away behaviors of the underlying hardware that can leak information.

I suppose you could extend the functional language's type system to tag data as e.g. needing to be compared to other data in constant time, or needing to be accessed in a particular way to avoid cache-timing attacks, and so on, but this just off-loads the problem to the compiler (i.e. the problem must still be addressed, and not in a high-level functional language). But if you're going to go that far, you might as well put the requisite safe code primitives into a shared library, so if you find bugs in them later (or discover new side-channels you didn't think about earlier), you can update the library without having to re-compile and re-deploy everything affected by it.

Re: Introducing Transport Layer Security in pure OCaml

#15

Post by pqwy »

richardwhiuk wrote: post #5

It looks like they have some odd cipher suite selection mechanic. https://tls.openmirage.org negotiates TLS_RSA_WITH_RC4_128_SHA which is the second worse suite that Chrome 35 will offer by default. If I renegotiate, the server will suggets TLS_RSA_WITH_AES_256_CBC_SHA, so it looks like the server wants to change the cipher later, which seems odd. This means it doesn't support PFS or several other advantages in the n…

Hey,

(Disclaimer: one of the authors)

We randomize the connection parameters on each connect to help us gauge the stack's behavior with various combinations (see https://github.com/mirleft/ocaml-tls/issues/159 ). Normally it uses first available from the list here: https://github.com/mirleft/ocaml-tls/blob/master/lib/config.....

(For some reason the RSA variant got on top; it should have been DHE_RSA, which does provide PFS.)

Side channel attacks were a very big concern, and I invite you to read the entire series of articles we plan on publishing in the next few days, where we try to lay down our strategy and explain what we know and what we don't. Or even skim through the handshake code and check some of the comments there.

We were already warned that CVE-2014-1266 CVE-2014-0224 are not memory safety issues. The article is badly worded there. What was meant is that they are, at least in our pretty firm opinion, issues with C (something we will elaborate in more detail in further articles, but in essence, you get regular control-flow in a functional language and you can encode state machines in a far more explicit manner). Working to update the post and clarify this.

As for the issue #6, yes, its closing was not documented too well. This does not mean we didn't expend significant effort to actually address the points there :) .

Thank you for the input and please have patience with us. We still have (at least) four more articles to publish!

Re: Introducing Transport Layer Security in pure OCaml

#16

Post by pqwy »

edwintorok wrote: post #6
emillon wrote: post #3

The work on Mirage is very interesting. If I understand it correctly, it may be possible to run a Xen domain with a Linux application server, and with a TLS reverse proxy in front using another Xen domain (in the form of a unikernel). This would be fantastic and does not change a lot how you run your application, except that you get hardened crypto for free. That's assuming that ocaml-tls has no "high level" bugs (no…

One thing that concerns me is the entropy source in Xen guest domains, but hopefully that'll be worked out for the final version.

It concerns us too. Right now the entropy in Xen domains is weak, but we are working with the rest of the team to feed some actual environmental noise to keep Fortuna well-fed.

You can also run the library on Unix, of course, and there the RNG is periodically seeded from /dev/urandom.

Re: Introducing Transport Layer Security in pure OCaml

#17

Post by pqwy »

edwintorok wrote: post #11
pdpi wrote: post #7

Earlier quoted context omitted.

For the sake of moving things forward: every time we have this discussion, someone always points out that functional languages would make it easier to get correct behaviour from a crypto library, and someone always replies that garbage collection opens you up to side-channel (timing, in this case) attacks.

The actual crypto primitives are still implemented in C, do those timing attack apply to the high-level part implemented in OCaml too?

That is exactly the question we have. And yes, the primitives are in C largely due to timing concerns.

Re: Introducing Transport Layer Security in pure OCaml

#18

Post by avsm »

richardwhiuk wrote: post #5

It looks like they have some odd cipher suite selection mechanic. https://tls.openmirage.org negotiates TLS_RSA_WITH_RC4_128_SHA which is the second worse suite that Chrome 35 will offer by default. If I renegotiate, the server will suggets TLS_RSA_WITH_AES_256_CBC_SHA, so it looks like the server wants to change the cipher later, which seems odd. This means it doesn't support PFS or several other advantages in the n…

Well done on noticing the slightly random cipher negotiation. That was actually deliberately put into the demo server on tls.openmirage.org to help us get more test coverage from visitors to the site (see the https://github.com/mirleft/ocaml-tls/tree/demo-random branch). We've mitigated most of the commonly known client incompatibilities, but there are no doubt obscure cipher-specific mitigations remaining, and the only way to uncover those is by forcing their negotiation ahead of better ciphers.

We've looked into timing side channels attacks quite a bit, but decided to focus on the core protocol support before tackling the big issue of data-dependent control flow attacks See https://github.com/mirleft/ocaml-tls/pull/49 for discussion on the Lucky 13 mitigation that isn't merged in for example.

Editing the goto-fail reference to reflect that it's not purely memory safety (but of course we believe that more structured programming abstractions will help mitigate this class of errors). I've asked Hannes about the #6 issue as well, as that shouldn't have been closed with no explanation -- do feel free to post queries on such issues yourself as polling HN threads for feedback isn't reliable.

Re: Introducing Transport Layer Security in pure OCaml

#19

Post by avsm »

edwintorok wrote: post #6
emillon wrote: post #3

The work on Mirage is very interesting. If I understand it correctly, it may be possible to run a Xen domain with a Linux application server, and with a TLS reverse proxy in front using another Xen domain (in the form of a unikernel). This would be fantastic and does not change a lot how you run your application, except that you get hardened crypto for free. That's assuming that ocaml-tls has no "high level" bugs (no…

One thing that concerns me is the entropy source in Xen guest domains, but hopefully that'll be worked out for the final version.

We're putting together a front/backend ring (rndfront/rndback) that will proxy entropy from dom0 directly into the guest. It'll take some time for this to percolate into the public cloud, so we'll need to do what Linux does in the meanwhile (harvest entropy from interrupt timings, attempt RDRAND, and so on).

The ENTROPY module type supports this sort of callback in 1.2.0: https://github.com/mirage/mirage/blob/master/types/V1.mli#L7...

(If you're interested in contributing, the entropy harvesting is in sore need of more eyes and help!)

Post reply on HN