Introducing Transport Layer Security in pure OCaml
openmirage.org
Introducing Transport Layer Security in pure OCaml
1–10 of 44 posts
Re: Introducing Transport Layer Security in pure OCaml
#2Looking at the development history it would appear that this project started in Feb 2014:
https://github.com/mirleft/ocaml-tls/commit/10b53cd1ebde0360... .
Writing an (almost complete) TLS 1.2 stack in such a short amount of time is amazing! (compared to how long it took for NSS to gain TLS 1.2).
Looking forward to the next blogpost in this series.
Re: Introducing Transport Layer Security in pure OCaml
#3The 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 (not memory corruption related) of course, but I'm quite sure that it is way easier to review than existing TLS implementations.
Re: Introducing Transport Layer Security in pure OCaml
#4Are 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 a solid TLS layer.
Re: Introducing Transport Layer Security in pure OCaml
#5It 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 newer protocols.
I'd be very interested to know about side channel attacks which may be possible in OCaml, as opposed to in another languages - there doesn't seem to be any discussion of them here.
They also refer to the Apple Goto fail bug as a memory safety issue - that's not true, it was a programming flaw that could be made in a GCed language.
Finally, if I look at the issue tracker I see things like https://github.com/mirleft/ocaml-tls/issues/6 - closed, with no explanation and marked as a security concern - which gives me no confidence that the issue was addressed.
Re: Introducing Transport Layer Security in pure OCaml
#6The 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.
Re: Introducing Transport Layer Security in pure OCaml
#7Are 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.
Re: Introducing Transport Layer Security in pure OCaml
#8It 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…
The blogpost does mention that implementing more cipher suites is a work in progress.
Edit: the server uses a random protocol version for testing purposes, so that might explain the odd renegotiations that you observed: https://github.com/mirleft/ocaml-tls/issues/159
Re: Introducing Transport Layer Security in pure OCaml
#9Are 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.
Interesting, I didn't know that. I always wondered why (non "functional") Ada doesn't get mentioned more often in these kinds of discussions:
Re: Introducing Transport Layer Security in pure OCaml
#10Earlier 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.
Interesting, I didn't know that. I always wondered why (non "functional") Ada doesn't get mentioned more often in these kinds of discussions: http://www.adaic.org/advantages/ http://www.seas.gwu.edu/~mfeldman/ada-project-summary.html
And it's "cousin" SPARK, which adds proof capabilities: http://git.codelabs.ch/?p=spark-crypto.git