Ivan Ristić

TLS Server Name Indication now in Apache

Apache 2.2.12, which was released yesterday (see the changes), now supports TLS Server Name Indication (SNI), which is an extension to TLS that makes virtual SSL hosting possible. At the moment, every SSL web site requires a separate IP address and that makes SSL deployment more difficult than it could and should be.

Don't get your hopes up, though. Although the extension was defined in 2003, the support for it is still very limited. For example, Apache's adoption means that, for the first time, SNI is supported in a major web server. (For the record, you could have used SNI previously with mod_gnutls, but mod_gnutls is not widely used yet.) It is only now that the extension begins to have a fighting chance.

However, the server-side support is not the main problem, although we are yet going to see it IIS. The lack of client-side SNI support holds it back. Although Internet Explorer supports SNI since 7.0, the fact that it does so only on Vista and more recent versions, means that we will have to wait many years for SNI to become practical.

Can you have too much SSL?

In response to my announcement of the SSL Rating Guide, Colin Watson left an interesting comment, which I thought would be better answered here.

Perhaps getting away from the issue of SSL configuration, and more onto application design, there's a couple of areas where I feel OVER-use of SSL might be a problem:

Overuse of SSL? Having previously stated (in my Secure Browsing Mode proposal) that I'd like to see the Web become a SSL-only place, I don't think overuse is likely. In fact, given my ongoing struggle to find a hosted blog or wiki service that uses SSL properly, I'd rather see overuse than what we have now — no security at all.

1. sites that ONLY operate under SSL, and are not available without SSL, even though most of the content is public and not in any way sensitive (does this over-use undermine confidence or increase distrust is other non-SSL sites?)

Even with web sites that do not contain sensitive content (no need for confidentiality), you'd still want SSL to provide authentication (are you seeing the correct web site?) and integrity (has anyone modified content in transit?).

2. sites that are generally not SSL, but allow content to be accessed using SSL by unauthenticated users (authenticated users always being forced to use SSL)

Actually, allowing non-SSL access anywhere on a site that requires authentication at some point is very dangerous. When you access a non-SSL site you have no way of telling if you are seeing the genuine site. A MITM attacker could have intercepted your DNS queries to redirect your HTTP requests elsewhere. He could have easily modified the site's content in transit. Either way, he's in charge of what you see. Links to an SSL-enabled portion of the web site could be rewritten to plain-text access. Similarly, such links could lead to an SSL-enabled site under the attacker's control. Granted, some advanced users would detect such an attack, most most users wouldn't.

Can you have too much SSL? I don't think so.

Announcing the SSL Server Rating Guide and the Public SSL Server Database

It is my great pleasure to announce two new SSL Labs projects today. Although I launched SSL Labs a month ago using something else as an excuse, the two projects I am announcing today are the real reason SSL Labs exists. After several months of hard work, my two projects are finally ready for the public.

1. The SSL Server Rating Guide is a no-nonsense SSL server assessment guide. From the introduction:

   The Secure Sockets Layer (SSL) protocol is a standard for encrypted network communication. We feel that there is surprisingly little attention paid to how SSL is configured, given its widespread usage. SSL is relatively easy to use, but it does have its traps. This guide aims to establish a straightforward assessment methodology, allowing administrators to assess SSL server configuration confidently without the need to become SSL experts.

   The general idea is to give people something concise to work with, something they can pick up and use in a very short period of time. The guide not only makes SSL server assessment very easy, it also gives clear guidelines on what good configuration looks like.

2. But what good is a rating guide if you don't have tools that will do the hard work for you? Noticing a lack of good SSL assessment tools, I built one and made it into a free online service. The Public SSL Server Database was born.

I hope you will find the projects useful!

Firefox SSL extensions

When I saw the email Adam Muntner sent to the webappsec mailing list, in which he advertises his webappsec collection of Firefox extensions, I immediately realised I wanted to do something similar, but for SSL. There are a few interesting SSL extensions for Firefox, but people generally don't know about them.

I ended up creating two collections: one for the extensions that work with the most recent version of Firefox, and another for the older ones:

• Firefox SSL Add-on Collections

Examples of the information collected from SSL handshakes

I've received an email or two asking me about the information I collected using mod_sslhaf, so I decided to make it available for everyone. Here it is:

• sslhaf-20090709-2.txt.gz

The file contains a list of unique user agents seen on SSL Labs, each with information on the handshake they used and the protocols and cipher suites they offered to use. For example:

Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_2_1 like Mac OS X; en-us) AppleWebKit/525.18.1 \
(KHTML, like Gecko) Version/3.1.1 Mobile/5H11 Safari/525.20
 Handshake: h3
 Protocol: 03.01

 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)
 TLS_RSA_WITH_RC4_128_SHA (0x05)
 TLS_RSA_WITH_RC4_128_MD5 (0x04)
 TLS_RSA_WITH_AES_256_CBC_SHA (0x35)
 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)
 TLS_RSA_WITH_DES_CBC_SHA (0x09)
 TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x03)
 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA (0x08)
 TLS_RSA_WITH_NULL_MD5 (0x01)

The information gives insight into how SSL is used in real-life, but it's not reliable enough to support any conclusions about individual clients. There are several problems I need to solve:

1. Parse User-Agent fields to group related clients.
2. Record request IP addresses in order to be able to verify the search engine clients are who they say they are.
3. Record request IP addresses to use them as a mechanism to determine forged User-Agent fields.
4. Deploy mod_sslhaf to multiple high-traffic sensors, in order to further minimise the possibility of using forged User-Agent fields.

Update (10 July): Now with no unknown cipher suites in the output.

Analysis of Googlebot's frugal cipher suite list

Two weeks ago, I announced SSL Labs and my technique for passive SSL cipher suite analysis. It won’t surprise you to learn that I've been carefully observing the cipher suites used in the requests that came to the web site since. (In fact, I announced the site slightly earlier than I had planned because I wanted to get my hands on some real-life data.) One client’s SSL fingerprint immediately caught my attention, because it supported only 4 cipher suites. It was Googlebot.

There were 115 visits from Googlebot in the two-week period, using 5 different User-Agent strings (although Googlebot will sometimes send a request without User-Agent set):

• Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
• SAMSUNG-SGH-E250/1.0 Profile/MIDP-2.0 Configuration/CLDC-1.1 UP.Browser/6.2.3.3.c.1.101 (GUI) MMP/2.0 (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
• DoCoMo/2.0 N905i(c100;TB;W24H16) (compatible; Googlebot-Mobile/2.1; +http://www.google.com/bot.html)
• Googlebot-Image/1.0
• Feedfetcher-Google; (+http://www.google.com/feedfetcher.html; feed-id=9430846974815548184)

The first one is by far the most common, although the other ones appear on regular basis. I used reverse DNS to verify that the IP addresses belong to Google, with the exception of one Feedfetcher request, for which I had to use ARIN.

As I’ve already mentioned, Googlebot's SSL fingerprint is quite short:

h2,03.01,010080,04,05,0a

The first token indicates the version of the SSL handshake used. In this case it’s h2, which is a code for the SSL v2 handshake. The second token indicates the highest SSL version a client is willing to support. Googlebot’s choice, 03.01, indicates that is willing to go as far as TLS v1.0. Modern browsers do not support SSL v2.0 so it's generally rare to see a browser use a SSL v2 handshake. Search engines don’t care about security but they do care about accessing as many servers as possible: they’ll compromise and support the weaker protocols.

What follows is the most interesting part: the codes for only 4 cipher suites. They are:

• SSL_CK_RC4_128_WITH_MD5 (0x010080)
• SSL_RSA_WITH_RC4_128_MD5 (0x04)
• SSL_RSA_WITH_RC4_128_SHA (0x05)
• SSL_RSA_WITH_3DES_EDE_CBC_SHA (0x0a)

The first suite is only valid with SSL v2.0, while the three remaining ones work in SSL v3.0 or TLS v1.0. It's obvious that, unlike with most other SSL clients, the cipher suites on this list were hand-picked. If I would have to guess, I would say that the motivation was to save on bandwidth and increase performance. It’s likely that all SSL v2.0 servers support the one SSL v2.0 cipher suite, while 3 suites are needed to support the rest of the Internet.

Assuming the reason for such a short list of cipher suites is frugality, I am surprised it doesn’t contain suites with weaker ciphers. A search bot doesn’t really care about security so it could afford to negotiate a weaker cipher and perhaps save some CPU cycles. Similarly, 3DES is significantly slower (than, for example, RC4) so it would be my first candidate for removal if I am concerned with performance. Thus, I am guessing 3DES is there for interoperability.

It would be interesting to get someone from Google to comment.

Interestingly, my net caught one search engine imposter, who claimed he was Googlebot, but wasn't. While I could have also used a reverse DNS lookup to determine what the imposter wasn’t, in this case I was also able to identify what it was—someone browsing the Internet using a Firefox 2.x browser with and altered User-Agent field. Nice!

Improved handling of SSL warnings in Firefox 3.5

Slightly over a year ago I discussed the SSL certificate error handling in Firefox. Where Firefox 2.x allows users to simply click through a warning about an invalid SSL connection, Firefox 3.0.x improves the handling and makes it difficult to access the invalid web site.

My blog post turned out to be quite popular, sparking a lively discussion, which spilled onto the Mozilla's Bugzilla when I filed two bug reports for Firefox:

1. Exceptions for invalid SSL certificates are too easy to add
2. Handling of invalid SSL certificates lacks in usability

The first bug report was rejected after a short discussion (still, I was happy to have been heard), but the second lingered on and, one year later, resulted in the change in how Firefox handles invalid SSL certificates. In Firefox 3.5, when you encounter an invalid SSL web site, you get a screen similar to this one:

Notice the improved language. The message now ways "[...] we can't confirm that your connection is secure", instead of "[a site] uses an invalid security certificate" (followed by technical mumbo-jumbo). Clicking the two headings at the bottom uncovers the hidden areas, which contain more information and the button to create an exception: