Security, Crypto, and Random Topics

SSL errors ain't what they used to be

12th-Oct-2007 10:37 am

Background
We've been making some changes to improve the security of SSL sessions. You'll start to see these changes starting in upcoming builds of Firefox 3. These changes will fall into two categories:

UI improvements that include support for Extended Validation (EV) certificates
UI to handle SSL errors

The first change is outside the scope of this blog entry (though they are important). If you want to get more information on those topics, you might start by reading Johnathan Nightingale's blog entries here.

This post describes the changes we're making to the error messages Firefox displays when you encounter an SSL problem. The most common problems we see are:

Expired certificate: The certificate that the SSL server sent to Firefox was expired. Certificates that have expired are not valid in much the same way that credit cards are not valid once they have expired.
Self-signed certificate: The certificate's issuer is itself. This type of certificate is most common in test servers, and on intranets. Banks, online stores, and other reputable businesses would never use a self-signed certificate.
Incomplete certificate chain: The SSL certificate chains to a CA (intermediate or root) that Firefox either does not have, or does not trust. In either case, Firefox cannot connect the dots to be sure that the site is who it claims to be.
Domain mismatch: The web address you are visiting says one thing, but the certificate was issued to a different address. A common scenario exhibiting this problem occurs when you visit http://example.com but the certificate was issued to www.example.com.

In previous versions of Firefox, we presented a dialog box that described the error and allowed users to continue anyway. The problem with this approach is that in general users don't know what the implications of such a decision are. We've seen many instances where people breeze by those warnings without a second thought. Software shouldn't ask users questions they cannot answer.

You can read more about the change to SSL errors on Johnathan's blog entry here.

Overriding errors: Exceptions
While in most cases the error page warns of a misconfigured server (or possibly an attack), there are some special circumstances when knowledgeable users will need to override these errors. For example, web site administrators might have an internal test or staging server. That server might use SSL, but with a self-signed certificate that Firefox would not be able to validate. In such cases, there is a way for knowledgeable users to override the error.

To override the error, you need to create an exception. The SSL exception dialog is located in the Preferences window, under Advanced/Encryption/View Certificates. Once there, click on the Servers tab, and then on "Add Exception...". The UI should be straightforward from there. You can add as many exceptions as you need for your testing purposes.

Sharing exceptions
There are also cases where administrators might wish to share their overrides between themselves. One admin might go through each of the internal sites that uses self-signed certificates. He can then share his override settings with other administrators. If you fall into one of these special cases, here is some information on how you can share override information.

The override definitions are stored in your Firefox 3 profile directory in a file called cert_override.txt. You can share the lines in that file that pertain to the web site in question.

For those of you who want to know more about the format of that file, here is the breakdown:

hostname:portnumber (primary key). The override is bound to this combination of hostname and port number.
OID of hash algorithm used to generate a certificate fingerprint. This is currently set to OID.2.16.840.1.101.3.4.2.1 which means SHA-256 and may change in the future.
Certificate Fingerprint using the algorithm from the previous field
One or more characters that define the time of override: M, U, and/or T:

M : allow mismatches in the hostname
U : allow untrusted certs (whether it's self signed cert or a missing or invalid issuer cert)
T : allow errors in the validity time, like expired or not yet valid certs

A special encoding of the allowed cert's serial number and the issuer name as a base64 encoded string (the database key obtained from NSS)

Note: when you update your cert_override.txt file, the browser must be shut down. Otherwise the file will be overwritten, destroying your changes.

Tags:firefox, mozilla, redhat, ssl, tls

Comments

22nd-Oct-2007 10:59 pm (UTC) - Poor UI

Anonymous

The exception override method is really hard to deal with when you have more than a handful of sites. Specifically, I have 96 machines with onboard out-of-band management cards (HP iLo) each with it's own self-signed certificate. That number isn't static - it'll grow as we (Mozilla) add more internal boxes.

It's painful to populate it once, let alone do it for each new server I add (and someone everyone else in the team has to do the same or somehow get a shared exception file that self-updates or something).

I get the point but I'm a power user and I should be allowed to shoot myself if I want to. I'd like to whitelist a whole network (range or CIDR notation) or sub-domain. And since I'm a power user, you could make it difficult but possible to do (which shouldn't be much different that network.security.ports.banned.override is).

- mrz

22nd-Oct-2007 11:15 pm (UTC) - Re: Poor UI

boblord

You make some good points. One interesting data-point is that some companies are seeing an increase in spear-phishing attacks against administrators, and even admins in "the security department". What I'm hearing from friends in these roles is that the attacks are increasingly sophisticated, and that given enough time, even seasoned admins fall for the attacks. So while you know more than a typical user, and argue that you should be allowed to shoot yourself in the foot, you may be underestimating the long term risk to your network.

In any event, I'll try to post a proposal (in a bug report, most likely) to give you more control over those nodes in your network soon. We can iterate there.

23rd-Dec-2007 10:43 pm (UTC) - Re: Poor UI

Anonymous

This setting without a disable button, however hidden, is like disabling all links in an email and disabling copy paste of said links. Sure, it'll decrease the number of phishing attacks, but at what cost to productivity? I've got about 400 domains that I need access to, all with self signed SSL certificates that don't match the domain. This means I can no longer use Firefox and I'm going to have to go back to using Safari.

23rd-Jun-2008 05:48 am (UTC) - Re: Poor UI

Anonymous

I tend to agree with the sentiment being expressed here. I work in an environment with over a thousand, unique self-signed SSL's being used. This is partly a customer-facing issue, and at least for some time most of our customers will not all, en masse, be switching to FF3 (I have to hope). However, our support department accesses these control panels on a regular basis for troubleshooting, and what was before a single click to acknowledge a valid (self-signed) certificate, is now a time wasting click through multiple UI interfaces.

Due to this poor design I'm already looking for ways to hack this out of FF3. Meanwhile, we will continue to use FF2 and hope that the Moz team will come up with a more suitable solution. Perhaps allow an exception to be generated to cert_override.txt that requires use of the master password? That way you can add an extra level of security by requiring the password to access the more "open" certification acceptance configuration.

Just a thought.

Cheers,

Jacob

4th-Aug-2008 03:27 pm (UTC) - Re: Poor UI

Anonymous

So clicking override four times is going to help keep me from shooting myself in the foot?

How many self-signed servers do I have? .. dunno, can't count that high.

... hmm. Clearly you have a good point, and SSL authentication is valuable, yes, but by effectively eliminating the value of self-signed certs (simple but strong encryption) you've thrown the baby out with the bath water.

suggestion:

1) Decide on some required field for self signed certificate. For instance, one of the fields = "selfsigned"

2) When this field is seen, a different message pops up requiring one click with an orange flashing "caution" light, maybe even in a traffic signal icon... "This certificate is not signed by a recognized authority but is claimed to be ok by (name, dept, etc). Please verify that you wish to proceed" and then flagging subsequent changes as a potential MITM (i.e., just as SSH does for changed keys)

Of course, for things like the HP ILO cards, it might not be possible to regen the certificate. In that case, some sort of fast "manual override" switch should be possible.

(joke - Firefox is becoming more like Vista: are you sure? are you really really sure? are you really really really sure? click here and dance on one foot to add an exception.)

2nd-Nov-2008 11:08 pm (UTC) - Re: Poor UI

Anonymous

No, please don't create Mozilla-specific standards. Just allow unverifiable certificates the same way you allow sites with no certificate at all (ie. no extra trust). Unverifiable certificates do not pose a risk to the user, only treating them as a method of authentication does. So why not just mark it with a red color in the same way you mark verifiable certificates as blue or green?

23rd-Oct-2007 06:00 pm (UTC) - Bug already created

Anonymous

Most of the issues around the new UI/process is already being tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=399275.

21st-Dec-2007 08:20 pm (UTC) - Further improvements

gkrall.pip.verisignlabs.com

Have you guys spent much time looking at the OCSP handling with a CRL backup if OCSP request fails? My experience has been that OCSP could use some help.

(no subject) -

vakfike1 Expand

12th-May-2008 03:24 pm (UTC) - Don't see exceptions tab

Anonymous

When I try to log into our firewall, I receive a certificate Alert with no way past it, just an OK button. I'm currently running "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.14) Gecko/20080404 Firefox/2.0.0.14" I had a version of three installed but have since uninstalled it. I may be in some "franken-zilla" situation, with parts for different versions. I'm being fully protected from phishing, but my Advanced/Encryption/View Certificates does not have an exceptions tab; I see only Your Certificates, Other People's, Web Sites, and Authorities tabs. Thoughts?

11th-Jul-2008 12:33 am (UTC) - Re: Don't see exceptions tab

vakfike5

It's painful to populate it once, let alone do it for each new server I add (and someone everyone else in the team has to do the same or somehow get a shared exception file that self-updates or something).

Tatil Yerleri

19th-May-2008 02:37 pm (UTC) - How it works with XulRunner ?

Anonymous

How can I make an lightweight navigator based on XulRunner to accept self signed certificat ? We test a lightweight navigator for special internal used, and, with XulRunner 1.9, we can't make it work with our own test certificat. With XulRunner, we don't have a preferences window and I don't understand how to create the cert_override.txt file.

24th-Jun-2008 07:24 pm (UTC) - Set my ILO's free

Anonymous

"Our data is so safe no one can get to it!"

It is a remarkably bad design decision to not have a reasonable way to accept a self-signed certificate. And a hand cut file of exceptions is not a 'reasonable' alternative. Virtually every network admin in the world is hating this, and hating even more being forced back to IE to make life easier. Is there a Vista designer on the team?

How about a switch somewhere (well hidden to protect the stupid, of course) to return the behavior to that of 2.x or IE?

3rd-Jul-2008 09:28 am (UTC) - localhost self-signed certificate

Anonymous

I am running a testing server on my local machine with a self-signed certificate. There is a huge problem though, Firefox won't even let me add an exception; it just pops up a dialog box that tells me the certificate is invalid. Even if I go to the options box and try to add an exception from there it won't let me. Even more odd is if I use the identical certificate on a remote testing server I can add an exception for it. What do I do?

7th-Jul-2008 01:20 pm (UTC)

- xulrunner application problem

Anonymous

We have a problem with xulrunner. We wanted to use xmlhttprequest to communicate with our server. When we used http:// things were fine. We though it would work with https:// also. Today we came to know that it fails because of self-signing. I am using xulrunner version 1.9.0.2pre - 2008070608
Actually we need SSL only for the reason that the communication happens with encryption. I would like to know if we can do something that the xulrunner client application accepts whatever certificate with out asking any questions.
To get the about:config , I used this in a xul window.

4th-Aug-2008 12:39 pm (UTC) - wtf... add your own CA to the certificate list, anyone ?

Anonymous

Why can't you just use a self-signed CA instead of a self-signed server certificate ?

If somebody needs to get a bunch of certificates out, this is the recommended way...
unless you don't trust the security of your *own* systems to ensure that your self-signed certificates cannot be hacked, I don't really see a point in issuing tens, hundreds or thousands of self-signed end-point certificates without the use of a self-signed CA to ease the approval process (unless you like it the hard, painful and dirty way... naughty ! But then why come here and cry ?).

It worked in Firefox 1, 2 and oh, surprise... it works for Firefox 3, who'd have thought that !
Well, at least for some companies and people it seems to work.

4th-Aug-2008 01:28 pm (UTC)

Anonymous

You are a douchebag

4th-Aug-2008 01:54 pm (UTC) - This is inappropriate

Anonymous

I love Firefox, and have supported it since well before 1.0. I love every new feature you've added over the years, except this one. The pop-ups that FF2 and other browsers used to display were already onerous, but acceptable. FF3's model brings it to the point where ordinary users simply don't know what to do.

This is not just a warning anymore. I know you provide a link to add an exception, but realistically you are *preventing* normal users from visiting a site they want to go to. There is a huge distinction between a warning and what you're doing. It is really inappropriate for a browser to do this, regardless of how good the intentions behind it are.

As far as those intentions go, in some cases an authority cert is actually impossible to use (distributing software with a built-in webserver). FF3's policy is causing these people to either lower their security level (by using HTTP rather than HTTPS), or switch back to IE/Safari.

4th-Aug-2008 04:17 pm (UTC) - Bad Firefox 3

Anonymous

I work with a nonprofit that uses self-signed certificates. You are putting an onerous burden on us. Bad move, for a browser we have recommended to our users for years.

What we use SSL for doesn't risk the user's privacy beyond what risks are already out there (i.e., wireless connections, etc.).

This is impacting our service to our users. We stand for net neutrality as an organization, and what you are doing essentially disregards net neutrality on this issue.

4th-Aug-2008 04:49 pm (UTC) - This is going one step back in usability

Anonymous

I have been using and trying my best to spread the mozilla products (both Firefox and Thunderbird). The usability is really great except that now we have gone back one step with this new "feature". You should remember that SSL is not merely used by sites requiring high-level of authentication and confidentiality, but also by sites/people who just want to make it a little more difficult for the casual sniffer from sniffing the requests/responses. The previous dialog of asking whether to continue was IMHO sufficient for the security-aware individual to dig deeper but also let the layman continue browsing with a single-click. With this new feature, it is scary to the layman to override what FireFox reports as being really bad and will continue if you add an exception to the rule.

Thanks for the great product but I would like to see this feature reverted.

5th-Aug-2008 06:28 am (UTC) - add self-signed CA into global list of OS

Anonymous

I have created selfsigned CA for intranet application and I want to use thi
in globally. as of now every user they have to import this certificate into
their profile directory. without this how can i achieve this globally in linux OS

10th-Dec-2008 07:45 pm (UTC) - Re: add self-signed CA into global list of OS

Anonymous

I agree with this. I am running an intranet site. IE makes it easy to push out a trusted certificate via the Windows Certificate Store. Firefox needs some way to do this.

I like the way fire fox works when I am using it, but I am going to have to tell my whole company that they can only use IE.

It is sad when the competing (suposedly nimble) option to IE starts taking the "Use it and like it" approch at that Microsoft so frequently employs.

8th-Aug-2008 02:33 pm (UTC) - The Nanny Complex

Anonymous

The Nanny Complex is growing everyday. Government is protecting me from myself. Do-good busybodies are telling me how to live. Finally, a browser has stepped up to the plate and gives me more warnings and click thru than the competing MS. WoW! Now that's something to be proud of.
Why do I have to click this many times? Because my small business simply cannot afford the yearly cert fees, I decided to self sign.
Sure, my data is encrypted, but look at my portal with FF3 and the casual user would run screaming from my site.

I think from the comments you have received over the past year, it may be time to rethink your strategy and I have the perfect fix! Go back to FF2 functionality. Or, maybe you might want to take a look at how Opera handles self signed certs. Heck even the MS product does a better job in the usability department... and that is a sad indictment.
My 2¢

18th-Sep-2008 05:35 pm (UTC) - One solution

Anonymous

At least internally, go back to 2.0.0.16.

This underscores another issue, which is lack of ability to administer LOTS of ff installations internally. All platform-independent, like.

22nd-Sep-2008 07:47 pm (UTC)

Anonymous

Thanks, my boss didn't like the error messages that came up when he (and his clients) went to our secure servers with self-signed certificates.

So I got to redesign how everything worked and had to buy "verified" certificates for all the servers. There goes my budget for a while.

1st-Oct-2008 09:24 am (UTC) - hardware with duplicate certificates

Anonymous

When all manufacturers of hardware that use https, implement unique certs in all their boxes this stupid 'feature' may be acceptable. Until then FF3 is no use to my organisation.

FF developers need to listen to their users and more importantly their ex-users!

16th-Nov-2008 02:07 pm (UTC) - One year later

Anonymous

and this terrible UI problem is still not solved. Why can't you just use openssh's very reasonable solution? Who are you, to be more intolerant about security than the obenBSD folks themselves?

Leave a Comment to the Entry

This page was loaded Nov 9th 2009, 8:21 pm GMT.