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