Signatures and Firefox Security

A blog entry written by Microsoft Employee Peter Torr about Firefox Security has been making the rounds lately. Simply entitled “How can I trust Firefox?“, it’s been linked by lots and lots of people (Slashdot got a hold of it for one) and I’ve been participating in the discussion over at Wizbang. (Torr has an update here).

Now once you get over the initial chuckle of a Microsoft employee criticizing another web browser’s security, go ahead and read the piece and the update. Go ahead. I’ll wait.

Back? Good. Let’s chat about security for a moment.

My background and expertise is computer security. I like it, I think it’s interesting, and it’s an area of CS that’s going to be getting more and more important as time goes on. Moreover, it’s not an area that is immediately obvious to even the most computer savvy of users. Most of the respondents to this article, though, are falling into a bit of a trap: they’re criticizing IE.

That, of course, is not the intent of the article, to say that IE is better, only that Firefox has problems. Only poorly informed Firefox cheerleaders or Anti-MS bigots <cough>Paul</cough> are going to try to argue that FireFox is perfect. It’s not, and that’s the whole point about open source… that software is never perfect, but that the best way to get as close as possible is to have as many eyes on the code as possible to find the problems. Torr is another set of eyes and regardless of who writes his paychecks we ought to be listening to what he has to say.

So because so many people over in Wizbang’s Comments seem to be poorly-informed on the topic, I had the urge to write about it. I’m going to try to keep the terms simple so that it doesn’t take a CS degree to decipher.

Basic Security
The security of a program, process, network, or anything else is only as strong as the weakest link — that makes a lot of sense if you think about it. If you have a building with 30 doors, and you only lock 28 of them, how secure is the building? It’s not. You’re hoping that the culprits don’t know which two doors are unlocked, and hoping that there are too many doors for the culprits to try them all. This is generally called “security through obscurity” — the notion that the best way to secure something is for potential attackers to be unaware that the problem exists. More to the example, it’d be like not locking the doors and hoping that potential intruders don’t realize they’re doors. Maybe you camouflage them or something. Who knows. Though there are arguments to the contrary, Security Through Obscurity is a Bad Thing™. It’s much much better to just lock all of the doors. Then it doesn’t matter if the attacker knows that it’s a door or not, he’s not getting in without the key.

Trust Issues
Torr’s argument was that one of Firefox’s doors was unlocked. Namely, that there’s a untrusted distribution channel. An axiom of responsible computing is that you should only install software from vendors that you trust. Another axiom is that trust is not transitive. If you trust PeteHoliday.com (and you should), and I trust hackers-r-us.com, does that mean that you inherently trust hackers-r-us.com? It shouldn’t^[#]. When you go to download Firefox (and you should) you get redirected to a mirror. That is, your download is not actually coming from mozilla.org (a site you should trust, I promise) — but a mirror… a site that THEY trust. Aside from the bigger problems that I’ll get to in a second, this is a small problem. It’s magnified because Firefox doesn’t give you a list of mirrors, it just sends you to one randomly ^[#]. How do you know that the mirror is a trusted site? How do you know that it’s even one that mozilla.org trusts? You don’t. All you know is that you clicked a link on mozilla.org and were presented with a dialog box prompting you to download a file from another site. Absent other authentication measures, this is a big no-no (albeit one that’s commonly encountered).

Points of Vulnerability
Bugs that cause security holes are going to happen. Lapses in security because of administrator error are going to happen. Malicious users who are trusted inadvertantly are going to happen. In short, you can pretty much guess that most every system of interest is going to be compromised at some point — computer security is not a game of perfection, it’s a game of trying to be perfect… and being able to react quickly when you’re not. That being the case, one big problem with mirrors is that they increase the points of vulnerability. By and large this is not a huge deal, but it is to be considered — now there are MORE people who are entrusted with access to the Firefox program downloads, and there are MORE servers to attack in hopes of finding a security hole. It also means that when a hole is found, there are more chances that it won’t be patched quickly enough to ensure that the server is not compromised. In short, it creates more links in the chain for weakness to appear.

Marginalizing Distribution Chain Security
Obviously, since mirrors are a common part of downloading on the internet, a big goal would be to eliminate the need to trust every mirror you download from. Surely some nerd has come up with a way that you can guarantee that you’re getting what mozilla.org wants to give you even if NEITHER of you trust the mirror. That’d go a good ways to eliminating the trust issues of mirrors, wouldn’t it? (Yes, it would) Well… luckily for you, some nerd DID come up with a way: public key encryption. The encryption is used to generate “signatures” by which you can verify the source of the message, and you can tell if the message has been tampered with. Neat, huh? How’s that work?

Signatures and PK Encryption
First, the quick and dirty version of PK Encryption… essentially it works like this: everyone has a public key and a private key. The public key they give out to anyone who wants it… the private key they keep to themselves and guard with their life. When something is encrypted with the private key, it can only be decrypted with the public key. The reverse also holds. ^[#]. Now, with this information we’re ready to use PK Encryption to validate a sender. Let’s look at signing an email, shall we?

Example Case: Signed Emails
Now, let’s pretend that you’re a security-minded person, and you want to guarantee that people can verify that you are the author of every email that you send. How can you do that? Well, obviously you could just encrypt every email that you send with your public key, and require people to decrypt it with the public key before they read it. This, of course, is annoying — and it means that some people might not be able to read your email. Not a good solution. This is where signatures come in.

Why not encrypt the email, add the encrypted email to the bottom of the normal email and send them both! This is called a “signature”. Your recipient could decrypt the signature with your public key — the fact that it decrypts correctly ensures that you actually sent it. Then you compare the decrypted copy to the plain copy and if there are no differences, it guarantees not only that you sent it, but that it was not modified. Awesome!

But wait… what if you want to send a 30 page email… using this type of “signature” it requires you to actually send 60 pages… 30 encrypted and 30 unencrypted ^[#]. What to do, what to do?

The answer, is “hashing” or “message digests.” These are algorithms that take any sort of input in any length and output a small string of characters that serves as a unique identifier ^[#]. The process is repeatable… that is to say that when you and I “hash” the same email using the same method, we’re going to get the same short string.

The application of the concept here is that you “hash” your email, encrypt that hash, and add THAT to the end of the email. When someone gets your email and wants to check its validity, they decrypt the signature, and compare it to the hash of the message that they themselves create. If they match, it’s all good. If they don’t, it means that something is wrong and the email is not to be trusted.

Application to Firefox
The application of the concept here is that if Firefox were to “sign” it’s code, as we described above, it would be MUCH more secure and trusted. This is even more true if the signature checking is embedded into the system that you’re using so that you don’t have to do anything by hand — your computer does the signature checking for you. I’m not 100% sure about this, but I believe that if you use a certain public/private key generating system, Windows WILL handle this automatically and let you know if the file you’re downloading is signed. Regardless, the bottom line is that the problems with the distribution chain of Firefox can be easily mended with a simple PK Encryption signature.

Regardless of who pointed it out — whether it’s the head of mozilla.org or Bill Gates himself, it ought to be taken seriously and fixed. If we simply ignore the bugs pointed out by Microsoft and try to make them look insignificant, it would benefit them to go through the Firefox code, find holes, and then point them out… let the OS zealots talk about why that’s not a big deal… and the publish some exploits… poof. The Firefox’s image goes down the crapper. Extreme case… but it simply illustrates the point: it doesn’t matter who finds a problem, it still needs to be fixed.