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:

1. UI improvements that include support for Extended Validation (EV) certificates
2. 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:

1. 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.
   
2. 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.
   
3. 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.
   
4. 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:

1. hostname:portnumber (primary key). The override is bound to this combination of hostname and port number.
2. 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.
3. Certificate Fingerprint using the algorithm from the previous field
4. One or more characters that define the time of override: M, U, and/or T:
1. M : allow mismatches in the hostname
   
2. U : allow untrusted certs (whether it's self signed cert or a missing or invalid issuer cert)
   
3. T : allow errors in the validity time, like expired or not yet valid certs
5. 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.

I'm pleased to announce that the nightly Firefox 3 builds now contain the Camellia cipher. The Camellia cipher was developed by researchers at NTT and Mitsubishi Electric Corporation. We expect that Camellia will be big in Japan in the coming years, and when Firefox 3 is released it will be ready to go. (At this point only developers and testers should be running Firefox 3 builds.)

We don't normally add new encryption technologies to Firefox, so this addition is rather special. In the encryption world, new is bad. Older is better. Ciphers that have been reviewed, deployed, and attacked repeatedly (and survived!) are best. To give you an idea of how rarely we add ciphers, the last symmetric cipher we added was AES in 2002.

Camellia also represents a great open source partnership. The Camellia team went to great lengths to publish their technology and to seek reviews. They provide royalty-free licenses to their patents. They worked through the IETF process to create RFCs for the TLS, IPSec, and CMS protocols. They wrote code to implement the cipher. They contributed this code to the NSS crypto libraries under the standard Mozilla tri-license. We were then able to incorporate Camellia into NSS, and then activate it in Firefox. That process took them years of hard work and diplomacy.

I am very impressed at how well the Camellia team was able to work through all these matters leading up to today's announcement. They have been a pleasure to work with! I look forward to more Firefox uptake in Japan as a result.

If you are running the nightly Firefox 3 builds, you can visit the Camellia test server and check the cipher you negotiated (Page Info): https://info.isl.ntt.co.jp/crypt/eng/camellia/index.html

Here is the bug report: https://bugzilla.mozilla.org/show_bug.cgi?id=382223

Here is the Wikipedia article: http://en.wikipedia.org/wiki/Camellia_(cipher)

Our RSA Conference panel talk on implementing ECC in the TLS protocol went really well.  We had a very full room, and people stayed until the very end.  There were numerous questions from the audience during the formal Q&A section, and several people came up to talk to us informally. Overall, it was a great experience, and I thank my co-presenters from Microsoft, Certicom, Sun, and the NSA.  They also did a great job.

There were a few well known people in the audience.  Sitting in the front row was none other than Whitfield DIffie, a true pioneer in the cryptography world.   I might have been a little intimidated at having such a dignitary listening to me talk if not for two facts.  First, I was well prepared and had interesting performance graphs and non-obvious lessons learned.  Second, he fell asleep around the time I was talking.  Or maybe he was deep in thought, pondering the deep meaning of my talk.

Yeah, that's it.