Security:SSLErrorPages

Overview

In Firefox 3, there is a desire to improve the existing UI around handling SSL certificates of questionable provenance. In Firefox 2, SSL certs which:

• Are expired
• Are revoked
• Are issued for a domain other than the one they are representing
• Do not chain to a trusted root (self-signed, unknown CA, &c)

are handled with dialog boxes (see Kai's page for samples). Those dialog boxes are difficult for users to understand, which encourages them to play "dialog box whack-a-mole" and do whatever is necessary to dismiss them. The dialogs facilitate this unsafe behavior by having unsafe defaults which accept the certificate as temporarily valid. These behaviors regularly draw criticism from the security community and create the potential to put our users at undue risk.

Changes in Firefox 3

Error Pages

The new behavior, tracked by bug 327181, will be to handle these conditions* (except revocation, see below) with an error page.

Unlike the dialogs, this error page will not provide a one-click option to extend trust to the site. Instead, after the diagnosis information, it will indicate that if you need to access this site despite these concerns, you must add it to your list of Security Exceptions.

Security Exceptions

Sites for which the user is certain that trust can be extended, despite the lack of a valid SSL trust chain, can be added to the existing "Web Sites" tab of the NSS/PSM certificate manager.

This workflow is complicated, however, by the need to have the cert stored locally on the file system before it can be imported. To simplify that process, bug 387480 has been opened to track the introduction of support for network-fetching a certificate, which will then be validated on the spot, and any issues called out. For certificates with non-fatal errors, a certificate fetched through this UI can be added to the list of exceptions, whereupon pages will load as before.

Host/Port Specificity

Exceptions which are added in this manner will be stored as a cert/host/port triple. This prevents a trojan self-signed certificate, issued against multiple domains, from getting itself trusted in an innocuous context and then exploiting the trust to masquerade as a target site.

Revoked Certificates

Revoked certificates are already handled by an error page, after the landing of bug 107491, as are all full-stop errors in NSS. They are not handled by the other bugs mentioned on this page.

Mixed Content

The discussions around this topic often end up touching on a related issue - the question of how to handle mixed content, of two kinds:

• Pages which serve a combination of (otherwise valid) https and http content. This is the traditional meaning of the term.
• Pages which serve a combination of valid http or https content along with https content on unknown provenance (expired, self-signed, etc.)

The first kind of mixed content is something we could answer far better if bug 62178 landed, since it allows us to drop unsecured content while still loading the page. It is currently in need of assistance crossing the finish line, though. Kai Engert had supplied a patch back in 2005 which is now bitrotting, and I'm afraid I don't have the docshell skills to make it happen. If you do, it would be a great help to get some eyes on that bug.

The second kind of mixed content is a tougher question. In Firefox 2, these pages would result in dialogs being presented for questionable-SSL-content as if the page itself were questionable, but if the dialogs are replaced with error pages, the question of what to do with that content becomes important.

Blocking this second kind of mixed content is consistent with the change in behaviour for the top level page, but fails to give users the same error text explaining the problem and mentioning the possibility of adding an exception. An option presented in the newsgroups and elsewhere would be to notify-bar in that case, but my concern is that the notification bar is relatively sparse as a mechanism for communicating about what is happening, and will lend itself too easily, I think, to one-click fix-it buttons.

My initial reaction here would be to treat it like other mixed content, which is to say that if we can't verify it at least as far as a valid, signed, non-expired cert, it doesn't belong on a secure page. In the strange-but-brought-up case of an http page referencing questionable-SSL content (e.g. a planet.m.o post which links to a broken-SSL image store), it obviously matters less - with the root page being unsecured, all the content can be altered anyhow - neither dropping nor preserving questionable content seems clearly advantageous.

Other Applications

While this page speaks in terms of the changes made to Firefox 3, the intent will be to implement this in such a way that:

• Other applications which can display error pages (e.g. SeaMonkey) will have the ability to do so
• Applications which cannot display error pages (e.g. Thunderbird) will be able to use the existing dialogs, though possibly with updated text.

Motivations & Objections

This move will obviously be unwelcome by sites which currently employ some kind of untrusted certificate. While there are certainly many sites out on the net using expired or domain-mismatched certificates, the loudest complaints are likely to come from users of self-signed certificates. These site owners are likely to object to the idea that Mozilla "force" them to pay for a CA-validated certificate, or to argue that it is inappropriate in their situation. This may include, among others:

• Corporate intranets
• Personal/Private sites which use self-signed certificates as a way of ensuring encryption.
• Hardware vendors shipping self-signed certificates for their web-based admin clients

For traditional web sites like intranets and other private networks, we think the concern can be mitigated, since users of those sites can perform a one-time configuration step to add the exception, and proceed as normal. Obtaining access to such sites (particularly intranets) often involves software configuration anyhow.

For hardware vendors, it is understandable that they should want the simplest possible configuration path, but this simplicity has to be weighed against the risk of allowing arbitrary certificates, making arbitrary identity claims, to be trusted in a simple and unintrusive way.

It should be noted in all cases that adding an exception for a particular self-signed certificate can help to reinforce security. Since any attempt by an attacker to change the certificate (e.g. via a Man in the Middle attack) will result in the error page being shown again, the potential exists for the user to be stalled enough that their suspicions are heightened. Clearly this argues for great attention to be paid to the error page text.

The overall motivation here is to eliminate the "default unsafe" behavior of our current SSL handling code. If it helps drive more of the https web towards verified certificates, that seems like a win, but is secondary to protecting our users. Making these changes trades off some ease of use in "unverified but actually safe" sites against some gains in security against sites that might be malicious. This is a tricky balance, and if you see holes in the current strategy, please let us know in mozilla.dev.apps.firefox.