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.
9 thoughts on “SSL Error Pages in Firefox 3.1”
This is really great, and I hope that it will help educate some people out there who were wondering what we were up to.
Do we have a different content page if the certificate has changed vs not being seen before?
I know that I typically nearly blindly type “yes” into SSH the first time that I connect to a server from a new machine, but I always pay very careful attention to the scary message that comes up if the cached signature is different from the one currently being offered by the SSH server.
I think you’re wrong about hiding self signed errors. The reality is that when developers use a self signed cert they are making a very different claim about identity than one that uses a root CA. In fact using a self signed cert makes almost no claims other than that your connection will be encrypted.
If that’s the case then why even tell users anything about ssl connections using self signed certs, in terms of the safety it provides it’s just like using a non-secure connection, so let them know that.
I wonder what kind of tests this comes with? If we could have, say, a litmus test explaining how to expose the variants of this dialog exhaustively, that’d help l10n a lot.
I’m sorry, but I feel that you have gotten the issue between identity and encryption confused here. It doesn’t matter if all the developer wants to do with a self signed cert is ensure that the connection is encrypted. If the browser and the user don’t take steps to ensure that the self-signed certificate delivered to the user did, in fact, come from the authentic site (e.g. the identity) then it is not effectively encrypted because there are too many push button man in the middle attacks that can replace an ssl cert with a fabricated self-signed one.
Just pretending that a self-signed cert is exactly the same as a plain non-secure site would be a great disservice to the many many sites relying on them. I want my e-mail traffic protected by SSL. I need to be told if something suspicious has happened to my certificate. I don’t want people to feel they can’t do business with a site that doesn’t fork over money for a premium certificate. If they have no capability to see that the connection can be considered secure as long as appropriate precautions are taken then that will be a failure.
The text “if you usually connect to this site without a problem” seems to beg another improvement: why not have the browser keep track of what certificates have been seen at what sites? Then the browser could be a bit more assertive with the message. The privacy issues should be handled like any other history mechanisms.
I’ve used the new SSL error page “in real world” this week several times. It works very well for me.
A question: You write that “Get Certificate” is gone, I still see it in recent nightlies. Isn’t that checked in yet? Will it show the certificates hash by default (I always know a few bytes of it and don’t bother to check more than those, still secure enough for me)? Now I still have to click “View…”.
Near the button “Get me out of here!” I will put another button to continue the navigation with the text “Continue navigation” or “See page” or something similar.
I understand the logic behind making permanent exceptions the default, but it would be very useful to have an option to allow expert users to change the default to temporary. When you deal with scads of devices that you fully expect will produce exceptions (i.e. SSL-enabled devices on a firewalled LAN) and you’d rather not make those exceptions permanent, the Firefox dialogs are a major pain.
More generally, I appreciate the emphasis on protecting naive users, but it’d be nice if Firefox provided a way for expert users to get their work done with minimal hassles. It sounds like 3.1 will get a little closer to that, which is good.
It’s not a safe practice in general, which is why I don’t particularly try to promote it, but there is an addon that might help in your situation:
It adds the exceptions without showing the dialog, and lets you specify whether they are temporary or permanent. It is an attack waiting to happen (hence the name) but in some circumstances, maybe you’re okay with that?