Elinor Mills' CNET's post titled Google making SSL changes, other sites quiet is interesting not just because it's about session cookies at some sites being vulnerable to MITM attacks, but also because it brings up a topic I've been talking about for years: Using SSL for all connections, not just for login. (See here, and here, among others)

She quotes Mike Perry:

"Just about everyone but Google simply does not want to spend the money to invest in the security of their users, and will continue to ignore this issue, just as they have for the past year," Perry wrote in an e-mail.

Mike is being generous. Companies have been ignoring this class of issue for the past decade. In 2008 web sites that deal in money or personal information (like email) need to secure 100% of all connections, 100% of the time. It is not enough to secure just the login pages.

And as for cost? It's not really about buying new machines anymore. (See my posts, linked above) SSL has been more than fast enough for years. It's really just a matter of inertia.

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.

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)

I went to the American Express site to look for information on travelers cheques and ran into yet another a sad example of what's wrong with the way major financial companies construct their SSL pages.

First, kudos to American Express for SSL-enabling their home page. Their heart is in the right place. If you type www.americanexpress.com into Firefox, you get redirected to a version of the web page that uses SSL (https://home.americanexpress.com/home/mt_personal_cm.shtml).  Bravo!!  Since they allow customers to type their user IDs and passwords on that page, it's important to have that page (in addition to the HTTP POST page) use SSL.  That way I'll know my name and password will be protected. (If it's not obvious why the page with the name/password field should use SSL, think about it for a bit... it's critical to the user experience, which is also part of the site's overall security.)

But in this case, I didn't want to log in.  I just wanted info from the Travel section of their site.  From the home page, I clicked on "TRAVEL" from the top of the page.  Instead of getting the page I expected, I got this warning:



Firefox shows this warning page when I'm on a page protected by SSL and the browser is instructed to send an HTTP POST to a page that is not protected by SSL.  You see this error very rarely. It represents a serious mistake on the part of the web site team. Behind the scenes there is a redirect or two and somewhere along the line there is an HTTP POST to a non-SSL page.  In general this is a simple problem to fix, though perhaps their content system does not allow them as much flexibility as they would like.

I don't care.

Some banks and other large financial institutions and merchants have consistently built web sites that incorrectly use SSL.  Given that they've had more than a decade (how many Internet generations is that?) to become comfortable with SSL, it's inexcusable that they can't get these sites built correctly.

When big companies that should know better introduce these types of errors, they inadvertently teach people that it's OK to click through these serious dialog boxes.   People incorrectly conclude that the warnings don't really mean much.  So when they are hit with a real phishing or other type of attack, they don't even see the warnings that are there to protect them.  They just click through.

These big players should be setting the bar high for correct SSL deployments.  Instead, they provide lots of examples of what not to do.

The NSS team has been preparing to submit the latest version of NSS for FIPS 140-2 validation at Security Levels 1 and 2.  We completed the necessary documentation, passed the conformance testing, and submitted our docs to NIST last week.  This week, NIST "pre-validation list" (Page 8 of the PDF) shows that NSS moved from "IUT" (Implementation Under Test) to "Pending Review". That means that the ball is in NIST's court, and they may take up to 3 months to issue the final validation certificates.

When the certificates are issued, it will be the fourth FIPS validation for NSS, the first being way back in 1997.

OK, I'm late to read George Ou's blog post from May, but it's worth a read: http://blogs.zdnet.com/Ou/?p=226

I'm glad to see more and more people expecting more from their financial institutions. We should be expecting nothing less than SSL on 100% of a financial institution's web pages.

ZDNet reports today that Yahoo and MSN are using SSL to protect IM traffic:

"We are encrypting all traffic that is sent across the [Yahoo and Microsoft] communities -- using SSL. On the other end we decrypt it and send the message to our users," said Karlsten.

Encrypting the traffic will ensure that the "path of delivery" is protected and messages sent between the networks cannot be intercepted by third parties, she said.

I suppose this is good, but I have to ask myself why they're so proud of themselves for encrypting traffic between the companies, rather than enabling encryption between customers.  In 2001 I led the effort to use CMS (Cryptographic Message Syntax), which is the message syntax used in S/MIME secure email, in AOL's AIM client.  That gave AIM users high-grade authentication and encryption when they IM'd with friends or business associates. Apple picked up that technology for their IM client as well.

This decision to not give customers real end-to-end security is disappointing, as is their claim that they are doing a great job:

IM security is a "top priority" for both Yahoo and Microsoft, added Karlsten: "As you can imagine, providing a safe experience is a top priority for both companies. We are doing everything in our power to make sure our combined global community will have a safe experience."

I guess "top priority" and "everything" are relative terms.

The Firefox 2 Beta 1 milestone was released today. There are a number of changes in the cryptography of this release that are noteworthy:

1. When Firefox makes an OCSP request to validate a web server's certificate, it now uses whatever proxy you set up for normal HTTP traffic. (Bugzilla Bug 111384)
2. Support added for Elliptic Curve Cryptography (ECC) in TLS. There's a test server here.  Please be gentle with this server. If it starts to melt we'll have to take it offline.
   
3. SSL2 is off by default. (Bugzilla Bug 236933)
4. The weak ciphers (keys less than 64-bits long) are off by default.
5. It supports the TLS server name indication extension to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. (See RFC http://www.ietf.org/rfc/rfc3546.txt)

Please run this software on a test machine.  It's a test release.  If you encounter any problems with the cryptography of this beta build, please file a bug here: https://bugzilla.mozilla.org/  (or contact me directly at blord at redhat)

The schedule for FF2 is at http://wiki.mozilla.org/Firefox2/Schedule and shows an August final release, but there's also a link to an online calendar that shows the final bits shipping at the end of September.

We continue to work towards FIPS 140-2 level 2 validation for the NSS crypto libraries.  When that effort is completed and NIST awards NSS the new validation certificates, people in the U.S. Government (and other places that value FIPS 140 validation) will be able to use the latest versions of Firefox and Thunderbird.

Brian Krebs' article in the Washington Post examines "cross site scripting" (XSS) as an attack vector for phishing. Although I don't doubt that some XSS attacks are possible, and that some have already been mounted, it's another example of people ignoring the big pink elephant sitting in the middle of the room.  Of course every web site should take steps to strip out any input that might be used in an XSS attack. 

But financial institutions and merchants should also be wrapping their entire site in SSL.  It's super cheap, and dramatically improves security. Simply put, sites that extensively use SSL are going to be nearly impossible to phish.  Why?  Because if you know that every Well Fargo page uses SSL (which it does!), you'll know that any Wells Fargo page without a lock in the browser's chrome is an attack.

He concludes:

If there is a silver lining in all of this XSS madness, it's that for the most part, phishers have been content to try to scam online banking customers by directing them via e-mail to wholesale counterfeit sites, said Dan Hubbard, senior director of security and technology research for Websense, an anti-phishing and e-mail security company.

"We've seen a several attacks in the wild that utilize [cross-site scripting flaws] on banking sites, and it's definitely a big future threat," Hubbard said. "However, right now there is just so much low-hanging fruit for these guys that it's kind of not needed."

That's exactly right.  Why bother with a sophisticated attack when for years the banks have taught their customers that they will not see the lock on login pages?  Just click on File / Save As... and phish away!