How to verify OpenSSL's Heartbleed patch is the correct one?

Question

In hearing about the Heartbleed vulnerability, I went to https://www.openssl.org/source/ to download the latest patch, but was quite surprised to find that the security certificate for that site has not been refreshed since the exploit was discovered ("not valid before" date is Tuesday, August 30, 2011 5:30:50 AM CT).

So, how can I be sure what I'm looking at is the true OpenSSL site and not an impostor who stole their certificate (even before the exploit was revealed).

In other words, I downloaded https://www.openssl.org/source/openssl-1.0.1g.tar.gz, which that same site claims to have an MD5 of de62b43dfcd858e66a74bee1c834e959, which it does, but is that the right fingerprint for that patch? Or am I downloading something malicious that has a new backdoor coded in it?

UPDATE: Following suggestion from @Lekensteyn, I verified that the PGP signature provided for that download was valid and signed by key 0xFA40E9E2, which seems to be the key of Dr Stephen N Henson <[email protected]> (which the the website agrees with). But to be super-sure, I'm assuming I can't trust the website right now. What other ways can I get faith that the 0xFA40E9E2 key is the one that should be signing that release?

Does anyone have an OpenSSL download from the 0.9.8 branch (that was not compromised by Heartbleed and would be old enough to have been distributed before the exploit), that they can verify is signed by that same key?

Concern: I found this notice of an update to the OpenSSL website, just before the exploit was revealed (April 2), and the change to the site was to mark Dr. Henson's key as expired, and add 0xFA40E9E2 as his new key, but that key was created back in 2005? So it's a new key to identify Dr. Henson, but then that's the key they chose to sign this super-important patch to Heartbleed? Does that seem off to anyone?

Answer 1

Your question is actually:

How can I be sure of the authenticity of the downloaded file?

Let's start with the details you mentioned. The checksum (MD5, SHA1, whatever) is a fingerprint of the file which allows you to check the integrity of the file. That is, whether the data has changed since the fingerprint was taken. If you get the checksum from a reliable source, then you can safely assume that the downloaded file is valid.

If you do not trust the checksum and want to authenticate the file, use the GPG signature if available. For the file in your question, this is available at http://www.openssl.org/source/openssl-1.0.1g.tar.gz.asc. If you trust the signer, and the signature matches the file, then you can assume that the downloaded file is valid. If you know nobody in its keyring, then you can look for others who trust it. For example, Debian has a copy of the signing key at http://sources.debian.net/src/openssl/1.0.2%7Ebeta1-1/debian/upstream-signing-key.pgp. This Tor script containg a GPG fingerprint of Dr Stephen Henson's private mail which has signed the openssl.org address.

If you are really paranoid and have older sources available, then you can download the file, extract it and compare the sources:

# Assume openssl-1.0.1f to be a known good source
tar xf openssl-1.0.1g.tar.gz
diff -Nur openssl-1.0.1f/ openssl-1.0.1g/

This requires some knowledge of the language in which the program was written (C for OpenSSL) though. If someone put in a backdoor, it would likely not be as obvious as // backdoor requested by the NSA.

Yet another alternative is to avoid the single download completely and fetch the sources from the source code repository at https://git.openssl.org/gitweb/?p=openssl.git. Some files may be different between the release tarball and the git repo (like the configure script), but the sources themselves should be the same.