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 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.
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.
(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!
> What was meant is that they are, at least in our pretty firm opinion, issues with C
I am very interested in the idea that ML can maintain security correctness under source line duplication.
It should be pretty easy to check for this condition too: for every line in every file, duplicate it. Discard instances where this causes invalid syntax; this will be most of them. Now either by running a test suite or inspection, see what the effect was on the program semantics.
But since by and large the lines we have are expression and not statements (the core handler is purely functional, using a monad to thread errors through), this amounts to type errors immediately.
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.