OpenSSL Security Advisory (opens in new tab)

[1] http://tweetnacl.cr.yp.to/tweetnacl-20140917.pdf

[2] http://blog.skylable.com/2014/05/tweetnacl-carrybit-bug/

"Bignum squaring (BN_sqr) may produce incorrect results on some platforms, including x86_64. This bug occurs at random with a very low probability, and is not known to be exploitable in any way, though its exact impact is difficult to determine. The following has been determined:

- The probability of BN_sqr producing an incorrect result at random is very low: 1/2^64 on the single affected 32-bit platform (MIPS) and 1/2^128 on affected 64-bit platforms.

- On most platforms, RSA follows a different code path and RSA operations are not affected at all. For the remaining platforms (e.g. OpenSSL built without assembly support), pre-existing countermeasures thwart bug attacks [1].

- Static ECDH is theoretically affected: it is possible to construct elliptic curve points that would falsely appear to be on the given curve. However, there is no known computationally feasible way to construct such points with low order, and so the security of static ECDH private keys is believed to be unaffected.

- Other routines known to be theoretically affected are modular exponentiation, primality testing, DSA, RSA blinding, JPAKE and SRP. No exploits are known and straightforward bug attacks fail - either the attacker cannot control when the bug triggers, or no private key material is involved.

[...]

This issue was reported to OpenSSL on 2nd November 2014 by Pieter Wuille (Blockstream) who also suggested an initial fix. Further analysis was conducted by the OpenSSL development team and Adam Langley of Google. The final fix was developed by Andy Polyakov of the OpenSSL core team. "

TLS is far too complicated with design-by-committee, special vendor extension sauce nonsense. Heck, the FIPS code was rushed and basically done at the behest of US/Canadian govts. OpenSSL should consider burning their deadwood and stop adding features until it gets its house in order.

There's no telling how large of an attack surface remains at the protocol level, in the codebase and with CAs being compelled to issue rogue certs for MITMs.

Moreover: Can TLS features be narrowed to focus on popular and high-value use-cases instead of SCTP, UDP, oh look a bird feature? It's fine for hacking on, but not production code. (If "TLS" is evolutionarily to "Perl," who's working on a "Python"?)

BTW: What ever happened to the cert WoT overlay 'moxie0 was working on?

"+!" If you want C-like behavior.

It'll be imperative with full dependent types as well.

Also interesting: cryptol, Irdis, coq, but the work is on making generic systems programming clear as possible in a static, imperative language without a titanic runtime or crawling along with superfluous assertions.

It absolutely would not eliminate CVE-2014-3570 or many other of the cryptographic bugs that show up in OpenSSL and other TLS implementations.

This kind of axiomatic thinking that memory safety equals all safety almost resulted in Rust being less safe (IMO) than C in these other respects: the normal types in rust are all defined to overflow even though overflow is almost always a bug, and so you couldn't use static analysis on arbitrary rust codebases to warn you about these issues (where you can in C because signed overflow is undefined, so an analysis tool can always flag that as an error without it being a false positive). Fortunately, it sounds like Rust is moving to fix this ( http://discuss.rust-lang.org/t/a-tale-of-twos-complement/106... ), which is a big improvement.

But it's important to not be fuzzy about the risks. There is a well established link between safety equipment and risky behavior in driving and bicycling; (http://en.wikipedia.org/wiki/Risk_compensation). I don't mean to suggest that better isn't better and we shouldn't use safer tools, but if our response to safer tools is to lower our vigilance, even the slightest, we may get worse results.

Yes, I have money. No, it wouldn't be a wise investment to throw it at OpenSSL. Some problems are subtle enough that merely throwing money at them won't make them go away. I also have the requisite talent and experience to make a sizable dent in rectifying the problems I have expressed in this library. However, that is also useless unless attitudes around the project are shifted so that such efforts would be maintained.

Fixing the project requires changes at the very top of their organization all the way down. At this point, nothing short of a fork -- which OpenBSD has done with LibreSSL -- may be enough to drive this sort of change. Which is, not coincidentally, why I donate money to the OpenBSD project.

LibreSSL, once it is mature, may be a good launching point for some of the ideas I have expressed here. However, I would have to see how that code base matures before making such a determination. It's a largely meaningless exercise unless people start moving to that library and away from OpenSSL.

It would seem odd if they actually change the build process in a security patch, right? The instructions on how to build OpenSSL on Windows has not been changed in 2 years.