Here are some interesting crypto performance factoids. We ran some tests to see how many RSA signing operations NSS could do on my work desktop machine. The results were better than I expected:

Using a 1024-bit RSA key: ~ 5,100 ops/sec
Using a 2048-bit RSA key: ~970 ops/sec.
Using a 4096-bit RSA key: ~172 ops/sec

So a good desktop machine can do almost 1,000 2048-bit private key operations. In software!   Note that we were not using a hardware accelerator. Just a good Intel-based CPU, running Fedora 8. Today most SSL web servers use the weaker 1,024-bit keys, though the 2048-bit keys will become more common in the next few years.

Your mileage will vary with the computer, the number and type of CPUs, and other factors that make meaningful performance measuring difficult. I was already convinced that SSL/TLS were fast enough to deploy extensively on a web site and even on entire web sites, but these numbers are icing on the cake.

Thanks to everyone who let us know that our Dogtag home URL was too hard to remember. Here is the new URL for our home wiki page:

http://pki.fedoraproject.org/

Please update your links and bookmarks to point to this page.

And feel free to join the mailing lists and join the IRC channels:

• http://pki.fedoraproject.org/wiki/PKI_Mailing_Lists
• http://pki.fedoraproject.org/wiki/PKI_IRC_Channels

Please let us know if you succeed or fail in getting the system to build or run!

In December of 2004, Red Hat purchased several technologies and products from AOL. The most prominent of those products were the Directory Server and the Certificate System. Since then we opened the source code to the Directory Server (see http://directory.fedoraproject.org/ for all the details). However a number of factors kept the work to release the Certificate System on the back burner. That's about to change.

Today, I'm extremely happy to announce the release of the Certificate System source code to the world.

This isn't a “Lite” or demo version of the technology, but the entire source code repository, the one we use to build the Red Hat branded version of the product. It's the real deal.

Our main wiki page will be here:
http://pki-svn.fedora.redhat.com/wiki/PKI_Main_Page

If you want to pull and build from source, start here:
http://pki-svn.fedora.redhat.com/wiki/PKI_Building

If you're just interested in grabbing a pre-built binary, start here:
http://pki-svn.fedora.redhat.com/wiki/PKI_Install_Guide

I invite you to sign up for one or more of the mailing lists:
pki-announce@redhat.com
pki-users@redhat.com
pki-devel@redhat.com
pki-commit@redhat.com

We also have an IRC channel for people to discuss the Certificate System on irc.freenode.net. The channel is #dogtag-pki. We hope to build an open source community of people interested in moving this project forward.

I started to use the Lightning plug-in today. (Lightning integrates a calendar into my Thunderbird mail client).  Despite the low version number (0.7), it works as expected. I subscribed to a number of public "shared" calendars and to my company's corporate calendar server. So now I can see my personal, work, and other public calendars in one place. I'm very impressed so far.

I wish I had done this before!

Silicon.com reports that a Salesforce employee was phished, which led to some of their customers being phished

Once the phishers had the contact list, they attempted to phish Salesforce.com customers. Harris wrote: "Unfortunately, a very small number of our customers who were contacted had end users that revealed their passwords to the phisher."

I don't think I've seen documentation of this sort of cascading phishing attack before.

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.

The buildings that housed the US Enigma codebreaking effort in Dayton Ohio are slated for demolition. See this NY Times article for more details. There's also http://www.daytoncodebreakers.org/ and http://www.building26.org/

As I mentioned in my last post, NIST issued FIPS 140-2 Level 1certificates for NSS. I'm pleased to announce that NIST has just issued the Level 2 certificate. You can see the notification here.

We feel that a Level 2 validation better represents the way our customers deploy NSS-based applications. For example, Level 2 testing allows us to run on a multi-user OS, in multi-user mode, whereas Level 1 requires that tests be conducted with a single user on the machine (which isn't how our customers deploy NSS-based apps). Level 2 testing is also performed on an operating system that "is evaluated at the CC [Common Criteria] evaluation assurance level EAL2 (or higher)".

Level 2 certificates for software are rare. And to the best of my knowledge, NSS is still the only open source crypto library to obtain a Level 2 certificate (the highest available for software modules).

This Level 2 certificate is a big win for the NSS team. Thanks to eveyone who helped!

NIST has issued the FIPS 140-2 Level 1 certificate for NSS 3.11.4.  You can see the certificate here. We expect the Level 2 certificate (currently the highest level possible for software) within a few weeks.  Although Level 1 validation is sufficient for most purposes, we feel that the requirements of Level 2 better reflect the way customers deploy security-enabled products, so we go to the added time and expense to achieve that higher level validation. 

This is the fourth FIPS validation for the NSS crypto libraries.

What does this really mean? 

First, we use this version of NSS in Firefox 2.x.  People who work in the U.S. Federal Government generally must use products that have obtained FIPS 140 certificates (when those products use cryptography).  Now that Firefox is using a FIPS 140-validated version of NSS, Government users can upgrade from Netscape Communicator (yes, you read that correctly) to Firefox 2.0. 

Second, RHEL 5.0 ships with this version of NSS as a shared library.  Apps like RHEL smartcard login, Firefox, and Thunderbird use this shared library and are able to inherit this newly issued FIPS 140 validation.  Further, we're embarking on an effort to NSS-enable a number of key applications in Linux (OpenSSH, stunnel, pam_pkcs11, etc.) to extend the reach of this validation.

Those of you who track this sort of thing in detail will want to understand this next point.  What we submitted to NIST for validation was not all of NSS.  Instead, we put all the code that was subject to FIPS 140 guidelines into a shared library module called the "Soft Token" (/usr/lib/libsoftokn3.so on RHEL). We very cleverly numbered the Soft Token module we submitted to NIST to be version "3.11.4".  So here's the confusing part:  "NSS 3.11.4" includes "Soft Token 3.11.4".  "NSS 3.11.5" and "NSS 3.11.7" also include "Soft Token 3.11.4". So it's not really correct to talk about NSS 3.11.4 being FIPS validated since NIST actually reviewed Soft Token 3.11.4. In hindsight, we should have started the Soft Token numbering with 1.0, and submitted "NSS Soft Token 1.0" to NIST.  Live and learn...

I'll update my blog when the Level 2 certificate shows up on the NIST web site.

Good news: NIST has moved NSS from the "Coordination" stage into the "Finalization" stage! This is, as the name would imply, the final stage on our quest to obtain our fourth set of FIPS 140 certificates.

I'll post again when we have the final certificates.