If you’re using Firefox 3.1 nightlies or the upcoming Firefox 3.1 beta 2, you might notice some changes in the way we handle SSL errors. I landed them last week, and since it’s a topic that readers of this blog have historically wanted to talk about, I thought I would highlight some of the changes here.
From a distance, without your glasses on, not much. We still spot situations that could signal a worrying lack of confidence in the integrity of the connection. We still use a content page to inform you of this, and to ask how you’d like to handle it. It sucks that we can’t make the call more automatically – that the attack situations are so hard to tell from the benign ones. What I’ve tried to do is at least make the experience more humane.
Let me mention 4 noteworthy changes:
- Leading with the human text, not the error code. The old pages were implemented using our generic error reporting framework, and that meant that things like technical details got top billing.With this rewrite, I’ve moved certificate errors off on their own, so that our users don’t suffer for our implementation woes. The technical details are still there, but they are now collapsed away until needed.
- Talking about the trust we have in the connection, not in the site. A certificate doesn’t attest to whether a site is trustworthy or not, whether its operators are scrupulous, or whether they have monkeys designing their shopping cart security. The real problem with these expired, mismatched, or self-signed certificates is that we don’t have any confidence that they are the “right” ones for securing your connection to the site.
Maybe that sounds frivolous to you, but I have spoken with a lot of people who said they supported the action Firefox was taking, but not the way it made them seem unsavoury. I think we now do a much better job here.
- Making the choice clearer. Getting people to read errors is hard, but it’s completely impossible if we teach them that reading just makes things more confusing. I’m convinced that the text here makes the choices, and risks, a lot clearer than they were hiding behind the “Or you can add an exception…” hyperlink.
- If you click the “Add Exception” button on the new page, the dialog will automatically fetch the certificate for you, instead of asking you to manually click “Get Certificate”. This was always possible to set up by changing the browser.ssl_override_behavior preference in about:config, our secret-handshake background config panel, but it was not particularly discoverable back there.
There were a couple reasons for Firefox 3 not doing that as well. There was some hope that having users interact with the dialog instead of just looking for the “whatever” button might be beneficial, but there was also a concern that pre-fetching the dialog would result in it being full of text as soon as users saw it, making it less likely that they would read it or understand the thing they were asking Firefox to do.
In the final analysis though, I think the time to try to engender that understanding is before they hit that dialog. So that seeing the report there of the certificates problems is just a final sanity check for a site they already know to expect this from.
What Didn’t Change?
We still show the error pages. People often ask why we don’t just wave self-signed certs through unmolested (possibly hiding the security indicators) instead of blocking them. As I mentioned when we introduced these pages, that punishes people with safe habits, and lets them get victimized by the man in the middle attacks that are getting much easier to pull off.
We still default to permanent exceptions. Sometimes people ask why we don’t do temporary exceptions which, being a lesser amount of trust, ought to be a safer default. The problem is, defaulting to temporary means that users see these error pages more often, which teaches them to ignore them. It also eliminates the modicum of protection we build up by being able to detect when a trusted self-signed cert changes. Adding permanent exceptions by default means that a typical user may not see this page more than 2 or 3 times in their life. Unless, that is, they’re on public wifi and someone starts trying to intercept their traffic, in which case it will pop up surprisingly often.
We still respect the expert pref, for users that deal with hundreds of misbehaving hardware boxes, or otherwise have an atypical need to frequently interact with constantly changing untrusted certs. If you are one of those people, going into about:config and setting browser.xul.error_pages.expert_bad_cert to true will tell Firefox that you are one of the edge cases. Combined with the pre-fetch above, this means that a user can add permanent exceptions in the same 2 clicks that it took in Firefox 2, but with significantly more humane language around it.
Ehsan just landed his Private Browsing work, Shawn’s got some awesome site-specific data-clearing cooking, and this week I’m busting my ass a little to get some improvements into our Clear Private Data code as well. When it comes to managing your security and privacy online, Firefox 3.1 is going to be awesome.