Wandering Thoughts archives

More on Firefox 3's handling of self-signed SSL certificates

One of my blogging flaws is that when I write up an entry, I can be so close to the issue that I leave important things out because they are 'obvious' to me. I did that with my recent entry about Firefox 3's handling of self-signed SSL certificates: I skipped describing exactly what makes Firefox 3's approach so wrong.

Firefox 3 is not wrong-headed for being cautious about self-signed SSL certificates, because there are real concerns with them in practice. Firefox 3 is so wrong because it makes it so inordinately difficult and obscure to actually accept them, especially for ordinary users.

(Doing so takes five clicks. At least one click is both inobvious and unnecessary, duplicating something that the browser has already done and should do automatically, and another one is one of those obnoxious 'are you really sure?' double-confirmation dialogs. On top of that, the entire process is wrapped in technical jargon. I know what is going on, but I doubt very many of our users would.)

This is especially striking because it was much less onerous to accept self-signed SSL certificates in prior versions of Firefox. A grumpy person could be left feeling that the Firefox 3 developers are basically passively doing everything they can to stop users from accepting self-signed SSL certificates, without being honest enough to outright forbid it (which I suspect wouldn't be politically acceptable).

Firefox 3 made these changes with the nominal goal of increasing the security of dealing with self-signed SSL certificate. What they have instead created is a process that is sufficiently complicated and opaque that in practice it will do one of two things, neither of them desirable. In the same way that users react to any other complicated multi-step dialog with too much text, either users will accept no such certificates at all because it is too complex, or they will blindly accept all of them because they don't actually read any of the dialog text, they just click on the buttons necessary to make things get out of their way.

The net result: frustrated users and no security. Double fail.

(If Firefox 3 really wanted to increase the security of dealing with self-signed SSL certificate, there are a number of things that it could do much better. On the top of my list would be clearly explaining to users in plain language what is wrong with the SSL certificate and how severe it is; a lot of users still won't read the text, but at least there might be a chance.)

Sidebar: in Firefox 3's defense

I don't actually think that the Firefox 3 SSL people have deliberately made the interface terrible (apart from the 'are you really sure?' double confirmation dialog sequence). What I think is happening is that they have not built a specific 'add exception' dialog for https connections that hit certificate problems. Instead they just start up some sort of generic 'add website certificate' dialog; because this dialog is generic, it forces extra steps and has a bad interface for this particular task.

How self-signed certificates are a problem for browsers

I was a little harsh on Firefox 3's handling of self-signed SSL certificates in the last entry, and in fairness I need to say that this is a genuinely hard problem for browsers, at least from a security perspective. Let us talk about just how this is so.

First, let us start with my previous basic model of how https could work. Browsers always use SSL if possible, and they protect against straightforward man in the middle attacks by remembering the SSL certificate they saw last time, or at least how strong it was, and complaining loudly if the SSL certificate is weaker. Call this the downgrade problem, and I believe that it's pretty solved.

(What does 'solved' here mean? To me, it means that you can accept self-signed SSL certificates while giving users the security that they think they're getting.)

This still leaves what I will call the initial connection problem. Suppose that the user types a https URL in that resolves to a site with a self-signed certificate, and the web browser has no SSL certificate information for the site on file; what do you do? Since the user explicitly typed in the https bit, they may well expect that you will give them full SSL protection, including genuine identity verification.

(Before people bring up SSH's handling of this, let us admit that only the paranoid actually validate those SSH host key signatures that OpenSSH tells you about; everyone else just says 'yes' automatically.)

One might hope that this was an uncommon case, but consider how often people empty their browser's caches for various reasons. And privacy concerns mean that if the user selects 'forget everything', we do need to forget the remembered SSL certificate information; clever hashing can't save us.

A related risk is using other people's computers, including public computers, and connecting to https sites; here an attacker might have preloaded their man in the middle self-signed certificates as the website's certificate, so the browser would see a self-signed certificate that matched the one on file. The counter argument here is that in practice there are lots of far worse things that can be done to public machines.

Why Firefox 3's handling of self-signed SSL certificates is wrong

There has been a certain amount of uproar about how Firefox 3 handles self-signed SSL certificates, and a certain amount of attempts to justify it. I disagree violently with the attempts to excuse the behavior, because what it comes down to for me is that Firefox 3 has made it more attractive to have no SSL certificate at all than to have a self-signed one. This is both insane and inane; it does nothing to further security on the Internet, and it has basically nothing to do with the sorts of real attacks that happen today (none of which require SSL man in the middle attacks, because people are not that suspicious).

(Sadly, Firefox 3 is far from alone in how it treats self-signed certificates.)

Now, man in the middle attacks are a real problem (or at least a potential real problem). But there are potential better ways right now of handling almost all of the problems that Firefox 3 is trying to confront, even if they are not as provably secure as forcing the user to jump through a succession of flaming hoops. And imperfect but usable security is much better than perfect but unusable security.

(I do sort of sympathize with Firefox 3, because there are hard questions. But ultimately I think that the hard questions are being used as excuses, unless people can show that there are significant active risks, not just theoretical ones. Real security always involves risk assessment and tradeoffs.)

SSL certificate revocation doesn't work (for web browsers)

How SSL certificate revocation is supposed to work is conceptually simple. The CA publishes a CRL, and SSL-using programs check the CA's CRL before actually accepting a signed SSL certificate. Despite this, SSL certificate revocation doesn't work on the web in either practice or in theory.

It doesn't work in practice because, well, it doesn't; you cannot revoke a SSL certificate today and have most web users notice. The only web browser that actively supports any sort of CRL checking is Firefox 3, and there is no clear sign that the CAs are actually providing revocation information to the certificate checking system that Firefox uses. Other browsers either have no support or have support but default to turning it off.

(Technically I believe that some browsers, especially IE, may ship with small static lists of revoked certificates. This is not meaningful certificate revocation.)

It doesn't work in theory because of those two vague words in the description: 'publish' and 'check'. This has two dimensions, the technical and the political. On a technical level, creating a viable system to do this is a challenging problem, because it must publish a significant volume of information, be queried at very high volume, and not impose significant bandwidth requirements on anyone or significantly slow down or impede https browsing (including when things go wrong), and all this while not leaking various sorts of private information.

On a political level, it is not obvious what CAs get out of actively and enthusiastically participating in certificate revocation checks. Certainly there doesn't seem to be any money in it for them, which leaves their economic interests misaligned with the goals of the whole thing.

(I'd say that the interests of the browser vendors aren't very aligned to this either, but browser vendors have a long and sordid history of being perfectly willing to make the user experience worse in the name of nominal and mathematical security.)

Sidebar: the pragmatic problem

All of this leaves unmentioned another problem: above all, any actively implemented certificate revocation checking must not misfire very often. In fact, it must almost never misfire. If it incorrectly identifies perfectly good sites as bad or otherwise blocks users from doing what they want with real sites more often than once in a blue moon, all that it will really accomplish is training users to ignore it or turn it off.

This is a significant risk given that a certificate's revocation status is currently unimportant information. There is a huge potential for all sorts of administrative mistakes to happen, causing perfectly good websites to fail.

(This is especially the case because in current usage, CRLs are supposed to list not just explicitly revoked certificates but ones that are obsolete for various reasons.)

Arranging your SSL websites for very cautious people

Suppose that you have a very valuable SSL certificate (for example, you are a bank) and a rather complex application (for example, you are doing online banking). You want to limit the damage of a compromise as much as possible and especially you do not want to have the high value SSL certificate compromised, because that would be a gold mine for sophisticated attackers.

Here is one approach to this problem that has recently struck me:

• your application runs on your pool of servers as usual, but each of them has its own DNS name and its own SSL certificate and you make these visible to the outside world.

• your normal https website, the one that users all know about and use, does not run your application. Instead, all it does is serve up (https) redirections to one of the pooled servers, using that server's individual name.

What this does is give you what I will call revocable names, DNS names that you can easily delete. You need this because the only way to limit the damage of a certificate compromise is to insure that the attacker can't use the certificate any more, and the only sure way to do that is to remove the hostname that's in the certificate.

Here, you have a system where the complex application is running on machines with revocable names. The only thing running on the one name that you can't revoke is your very simple central redirection server, which is much less likely to be compromised. (You can use a variety of techniques to force users to always go through the central redirector instead of bookmarking their favorite application server and returning directly to it.)

If you are willing to run slightly more code on the central server, this whole situation is natural for something like Kerberos. The central server is the only place that handles logins; when you log in, it passes a Kerberos ticket for you to the application server that it has determined will handle your session. The complex application never sees your credentials in any form, just a time-limited ticket it can use to get and put certain data from the backend on your behalf.