Security assessment in docs?

[Blaisorblade]

I was looking for a secure SSL implementation for Haskell (while investigating the best fix for ndmitchell/hoogle#92), and this looks like a good candidate.

However, I don't find sufficient documentation on the security of this library. I don't want to attack you, I appreciate the work, but the README does not explicitly discuss the security of the library, so I thought I'd ask. Moreover, while without docs I'd assume the library is insecure, less security-conscious user might assume it's secure if there's no warning against that, so it would be nice if you were explicit about it.

I've skimmed the README on Github, the main hackage page and the docs of the main module, and came back empty.

Some commenters ask whether such an implementation is safe against timing attacks. I found your answer, but:

• some people ask how do you prevent GHC from introducing timing vulnerabilities, and I see no answer. Which makes sense, because a suitable auditing is IMHO a research problem.
• that answer is not linked from the README. I think the docs should contain such a discussion.

The only other example of such an effort I've found is one in Ocaml. I've skimmed the page, and they seem to document explicitly what has been audited, which attacks have been mitigated and what hasn't — for instance, they write "for the time being we suggest to not use the stack on a multi-tenant shared host or on a shared host which malicious users might have access to."

[vincenthz]

yes, the security documentation is not as much written as I would want. You're more than welcome to start such a document listing potential problems (generic tls one or more specific one), that would help me getting this documentation started

[Blaisorblade]

Thanks for the positive reply. And sorry I won't start this document myself: I prefer somebody with more of a clue doing that.

I'd add a statement to the README pointing "this has not been subject to a full security auditing" or some such disclaimer, but I'm not sure I should propose a phrasing.

From the other comment:

The fact that you (and @abacabadabacaba ) are focusing on timing attacks [1] whereas they are so many things that can go fundamentally wrong (think Heartbleed, think apple crypto, basic logic errors, Denial of service, etc) tells me that you're not having an honest thinking about this. I'm all for skepticism in the face of cryptography and security, and anyone should doubt security stuff (that include openssl, which seems as usual to get a free pass here), but there's no point repeating common "knowledge" out of the internet about cryptography and trying to pass it as an educated thought.

Sorry about any of that, and I'm sorry it's not very constructive, FUD and so on. I'm not advocating for openssl: I'm at most a user of cryptography, so I can at most evaluate discussions of existing libraries. And the result here is "I can't use this library currently without analyzing the threat model myself - do I care about timing attacks, X, Y and Z?".

However, I mostly liked the code I've seen, FWIW; my sincere impression is that you are competent enough. After learning about timing attacks against memcmp, I've examined it. I've seen your constant-time comparison function, and I've seen the many instances of deriving Eq (which risks being non-constant-time), which however seemed fine (especially because you often use SecureMem, which is a great primitive!) because they are just on protocol IDs (and I'm guessing that's fine, though what do I know?). But I need to guess that you've put thought into this.

The only suspicious Eq instance I found was one on AESIV: this is probably safe, but if so for much trickier reasons. Quoting:

If an attacker knows the IV (or the previous block of ciphertext) before he specifies the next plaintext, he can check his guess about plaintext of some block that was encrypted with the same key before (this is known as the TLS CBC IV attack).[9][http://www.openssl.org/~bodo/tls-cbc.txt]

Is there a comparison which leaks IV before it is used so that an attacker can do such an attack? It sounds extremely unlikely, but I'm not sure. It certainly deserves a comment.

[vincenthz]

the IV is never a secret value (so leaking something public through side channel is not a problem), however most of the time (including in the case you're talking about), the attacker shouldn't be able to guess the IV we're going to use. Otherwise he can try to tweak its input to be able to "counter" the future IV for example.

[Blaisorblade]

Thanks for the answer. There would only be a problem if the code uses the AESIV "too early" enabling the attacker to guess (which sounds unlikely, but what do I know?). Either one uses SecureMem "just so" to be safer, or checks against this attack, or drops the Eq instance if possible.
(Can't help more for now, sorry about that).

[edgmnt]

I'm interested as well. But regarding timing attacks, wouldn't it be easier and safer if we wrapped computations in (tweakable) timeouts for now? It won't thwart side-channel attacks on the same machine, but it looks like a very straightforward, blanket fix.