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.

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.

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.