mitigate heartbleed vulnerability

[daira]

Check the OpenSSL version number and refuse to run if vulnerable.

Also see #2222 (make a FAQ describing the impact of heartbleed on Tahoe-LAFS).

[daira]

Also see ​http://foolscap.lothar.com/trac/ticket/220.

[daira]

Review needed for ​https://github.com/tahoe-lafs/tahoe-lafs/commits/2215-refuse-vulnerable-openssl.

(This should not be committed until we have built some non-vulnerable pyOpenSSL eggs.)

[zooko]

I've reviewed ​https://github.com/tahoe-lafs/tahoe-lafs/commit/e8ab8a7487489f84c3d474469127830f9d67e74b and ​https://github.com/tahoe-lafs/tahoe-lafs/commit/e22adb5edd41786b3498d6ab4040ee47ae4c4b95 . Looks good to me!

[daira]

The current branch implements a different policy:

• versions 0.9.8y+ in the 0.9.8 series are allowed;
• versions 1.0.0l+ in the 1.0.0 series are allowed;
• versions 1.0.1d through 1.0.1f are allowed iff compiled with -DOPENSSL_NO_HEARTBEATS or with a build date on or after 6 April 2014;
• versions 1.0.1g+ are allowed.

Also,

• the error handling has changed;
• there are more tests covering the cases above.

Re-review needed.

[daira]

Please refer to ​http://www.openssl.org/news/vulnerabilities.html for information about when vulnerabilities were fixed.

[daira]

It was suggested on #cryptography-dev that (rather than looking at build date as the patch currently does), we should call the tls1_process_heartbeat function to directly check whether it is vulnerable. (This is possible without invoking undefined behaviour.)

For pyOpenSSL >= 0.14, this can be done relatively easily by importing OpenSSL._util.lib, which gives access to arbitrary OpenSSL functions via cffi. For pyOpenSSL 0.13, however, it's basically impossible because there is no way to add to the set of OpenSSL functions exposed by the extension module. I don't know where that leaves us, given the cffi-related build problems described in #2193 and #2117.