Do not purchase if tamper-evident seal is damaged

Leviathan Security this week managed to catch, red-handed as it were (the malicious server appears to be in Russia and is even named, puckishly, kulak), a Tor exit node actively patching software and modifying it as it came over the wire. Long hypothesized but now finally demonstrated in the wild, this particular node was looking for uncompressed Portable Executable (Windows) binaries and monkeypatching them on their way back to the requester. In fact, it was so active that it gave itself away by trying to patch nearly anything that looked like a Windows application; a smarter node would only patch specific binaries and pass others unmodified, meaning these stealthier malefactors may never be discovered by security researchers even if they do in fact exist.

This applies to unencrypted downloads, of course; assuming no flaws allowing a man-in-the-middle attack, this sort of screwing around would be immediately obvious on a TLS connection. On Google Code, we had encrypted downloads, but Google Code (meanie) no longer allows uploads (scum); SourceForge's mirror network only supports regular HTTP downloads, which are not encrypted (please upvote this ticket if you have an SF account).

Are we high risk? No. You probably have a higher risk of developing Ebola than getting a tainted TenFourFox. It's hard to patch a compressed binary in flight, so it would almost certainly be a complete substitution, it would have to be done on a machine that can build such binaries and it would need to do something interesting on a Power Mac, and given all those preconditions frankly I'm not aware of someone who hates me that much except possibly the cute shop girl at the AT&T store who won't give me her phone number.

Still, I'd like to guard against that possibility, or of any network-imported code over an insecure channel (network snippets, for example, can be loaded into the start page -- which has chrome privileges -- and this should make you suddenly feel very icky and vulnerable). This ties in nicely with a recurring thought I've had of redoing the new tab and start pages so that we're not getting snippets from Mozilla anymore about browser things that don't really apply to us or aren't otherwise compatible. To that end, I think publishing a verifiable hash for all downloads and redoing the new tab (possibly just using a blank one?) and start page for 38ESR will achieve that. We also need to ensure the following:

• It should not require any special software to verify the hash. You should be able to do it with the tools that come with 10.4.11.
• The hash list needs to be secure, or that could be tampered with too.
• The new tab and start pages should not do network loads.

Here's how we'll accomplish that:

• The most secure hash algorithm that comes with Tiger's built-in OpenSSL appears to be RIPEMD-160; it doesn't support SHA-2, or I'd use that. RIPEMD-160 is a less common hash function but to date cryptanalysis has not demonstrated collisions so far with known attack methods (here's some light bathroom reading on that topic). You can verify that the .zip file downloaded properly by simply going into Terminal and typing (this is the actual hash):

  % openssl dgst -ripemd160 TenFourFox7450-31.2.0.app.zip
  RIPEMD160(TenFourFox7450-31.2.0.app.zip)= e6637dff473f68d2b4a4b6b920c70183d8658dea

• While we can't upload to Google Code any more, we can certainly post things. The Google Code project page is secured by SSL -- https://tenfourfox.googlecode.com -- and the hashes will either be listed there or on one of the wiki pages. You can grab the hashes securely before you update, download the file from SourceForge, and check that the hash matches. If it does, you have excellent assurance it has not been tampered with in transit. Hashes will be posted for the changesets too.

• We'll be taking the network and dynamic code out, which as a side benefit will reduce their overhead, and possibly some other minimizing changes. I'll probably still allow the old pages by an about:config switch, though I haven't really plotted how the infrastructure will look either. Just expect this for the next ESR.

Assuming no one finds any glaring holes in this idea, I'll probably implement the hashes for 31.2.0 and the 34 changesets this weekend in my copious spare time. It's just a little bit of extra insurance for our users who may be in more difficult circumstances.