SSL Blacklist 4.0


Intro


If you know why you're here and what the "SSL Blacklist" extension does, you can install it from here, or from the pretty link in the right column. Otherwise, read on for a description and some tech details.

Update 12/31/2008

SSL Blacklist now detects and warns about certificate chains that use the MD5 algorithm for RSA signatures.

An attack has been demonstrated yesterday that highlights the practicality of the well-publicizedpdf weaknesses of the MD5 algorithm. Essentially, any certificate signed with the MD5 algorithm may be counterfeit.

The demonstrated attack has two notable prerequisites: the ability to predict information in the prefix blocks of the data, and the present existence of CAs that use MD5-RSA to sign CSRs.

Since RapidSSL quite quickly switched to SHA1, the latter prerequisite seems to be harder to come across. (They issued a certificate to me at 9am this morning, less than 24 hours after the attack has been publicized, and this certificate no longer uses MD5.)

There is, however, a large number of CAs out there, and it is certain that some of them will continue to use MD5 for one reason or another. As for predicting information in the prefix block: some CAs may make this harder than others, but some low-volume CAs may require even less of an effort than RapidSSL did.

The real issue is, however, that this current attack is just a sign of things to come. MD5 has been known to have been weak for years, and now a small team with relatively modest resources essentially gained the ability to spoof any secure website on the Internet. Things are likely to accelerate from here and newer, more devastating attacks on MD5 are likely to surface soon.

Therefore it may be prudent to avoid, or, at the very least, not place much trust in websites that authenticate themselves with the help of MD5. After all, there is no way to automatically distinguish between a chain with a genuine MD5-based certificate signature and a chain with a counterfeit certificate. This recent update to SSL Blacklist will help you do just that.

MD5 has been all but retired from daily use for years now. You're not very likely to come across an important website with a certificate that has been signed using MD5-RSA. If you do, however, tread carefully.

A quick note on root certificates signed with MD5-RSA: these exist in abundance, and they're quite notable, such as the "Thawte Premium Server CA" from 1996. Fortunately, nothing indicates that root CA certificates that are distributed with client software would be of any risk, even if they have been signed using MD5-RSA. It's certificates that your client software does not already have a copy of, such as certificates issued to servers or intermediate CAs, that you have to be careful with. SSL Blackist by default will ignore root certificates that are self-signed with MD5-RSA, but will check every other certificate in the chain. You can change this behavior on the Options dialog, accessible from the Add-ons menu.


Overview


There's been quite a bit of reporting and discussion about the fix for Debian bug #363516 that's gone horribly bad. Some of it's really funny. Unfortunately, the problem is a big one.

A quick, one paragraph rehash: all RSA & DSA keypairs generated with OpenSSL on affected systems (any Debian-based system between roughly Sep-17-2006 and May-13-2008) are trivial to guess. The fix is not so simple. After updating OpenSSL on an affected system, you need to figure out if any of your crypto keys are affected. Keys are affected if they have been generated on a system with the crippled OpenSSL stack (or, in the case of DSA keys, simply used to log in from an affected system to any other system). You need to regenerate all such keys and replace your SSL certificates as well.

Why does this concern me? I'm not a big Linux user, neither at home nor at work. We patched the few Linux systems that we had to patch, we've regenerated the affected SSH host and user keypairs. We haven't generated any SSL CSRs on Debian, so we're cool, right? Well, not really.

Debian is a pretty popular Linux distro, and rightly so. This means that there are many websites out there running on Debian - and visiting an SSL site running on a system that has been affected by the bug may mean that the SSL certificate in play is essentially worthless and does nothing to secure communications between my browser and the website I'm visiting. What's even worse, I have no way to tell if this is the case.

Of course if the site's admin is doing his job well, then they're going to get their bad SSL cert reissued. Most CAs will do this for free. (If you run your own CA then this is even easier... just look here, these sites have really fresh certs with telltale timestamps, demonstrating that their sysadmins know what they're doing: alioth.debian.org and nm.debian.org.)

But what about the rest of the world? How do I know that the next time I'm buying shoes or books or whatever online, entering my CC info, the information is really secure? Unfortunately the CAs aren't rushing to revoke bad SSL certs. What's more, for testing purposes, I've generated a CSR on an Ubuntu system which had a crippled RNG, and GoDaddy was quick to sign it for me. It's right here: https://bad.codefromthe70s.org. See? Looks perfectly fine, looks secure, but it's absolutely worthless.

CAs should not be signing CSRs that are based on bad keys - and they should be revoking existing certificates too. Unfortunately this isn't happening. (UPDATE Aug-12-2008: I've received reports that StartSSL was one of the first CAs to filter for bad keys, and others, such as GoDaddy and Netlock have followed suit. I've even received an automated email from GoDaddy about the test certificate I have on bad.codefromthe70s.org.)


The FF Extension


So I decided to put together a Firefox extension that can detect bad certificates for me. It only took a few hours after the release of SSL Blacklist for a user to find a website with a bad keypair.

If you use SSL Blacklist and you're alerted of a site with a bad certificate, use the "Report" button. So far 445 bad certificates have been reported.

Here's what the extension looks like when it detects a problem:


SSL Blacklist in action
(click to enlarge)

The Ubuntu folks have published an openssl-blacklist package that contains fingerprints for 1,179,648 known bad keys. My SSL Blacklist extension incorporates the openssl-blacklist databases, and will warn you when you're accessing a site that is not secure. This should go a long way towards giving you some peace of mind.

To grab the extension (signed code with a signed updater mechanism), just click the link to the XPI in the right column. IE users should check out a similar utility published by Heise.


Under The Hood


The blacklist database is positively huge: the nature of the OpenSSL bug was that it'd generate one of precisely 98,304 keypairs on any given architecture for any given key length. The number of possible keys per architecture per keylength is three times 32,768: first, 32,768 possible keys with the ~/.rnd file, 32,768 possible keys without one (first runs of OpenSSL), and finally, 32,768 possible keys with an unreadable ~/.rnd file (such as when OpenSSL is invoked with sudo and the file becomes unreadable). All in all, 32,768 x 3 x 3 x 4 = 1,179,648 keys, covering the most common platforms (x86, x64 and PPC) and most common key sizes (512, 1024, 2048 and 4096 bits). The current database format uses 51 bytes per key - there's some redundancy in there which is mitigated by compression but there's not much that can be done to make the files significantly smaller. The local database, however, is now purely optional:

This new version of SSL Blacklist, by default, uses a DNS-based distributed online service to handle lookups. When you visit an SSL site, the modulus of the certificate's public key is hashed, and the hash is queried from the DNS database. If there's a hit, a warning is presented. Both positive and negative DNS responses are cached in the browser with a one-month expiration date. This ensures that the DNS requests are kept to a minimum. This is mainly done to mitigate any privacy-related concerns that users may have. Even if URLs are not sent to a 3rd party server, only the hash of the certificate's modulus, it's best to keep such traffic to a minimum.

If you are very much concerned about privacy, you should install the "SSL Blacklist Local Database" extension alongside with "SSL Blacklist". This will put the entire 31MB download (60MB uncompressed) on your computer, and SSL Blacklist, when it detects this "sister extension", will only use the local database for modulus checks.

If online installation does not work for you for some reason, you can download the XPI packages from here: sslblacklist-4.0.32.xpi and sslblacklist-localdb-1.0.8.xpi.

The Online Service


The DNS-based database is implemented via the modulusblacklist.org domain. This is a simple domain whose nameservers answer with a certain A record (127.0.0.2) when known-bad "hosts" are queried, such as 020b881ecc8bd1fb12b7d5361c9a90e339203666.modulusblacklist.org. When it receives requests for modulus hashes that it does not know about, it responds with a different A record (127.0.0.3), signaling that the key is not blacklisted.

Doing all this via DNS was a pretty obvious choice in retrospect. First, the database is fairly static so it was possible to convert it to a giant zone file and forget about the whole data processing aspect of the backend: the DNS server software handles requests, lookups and responses. Second, the protocol is extremely lightweight. Third, it scales very well, because caching is inherent in the DNS protocol. Fourth, it's very easy to have multiple servers act in a redundant and load-sharing manner.

The only downside DNS has versus, say, AJAX over SSL is that if an attacker can be in-path between you and an SSL site you're visiting and intends to exploit a weak certificate (which is probably what you're worried about), then spoofing DNS responses (and therefore rendering SSL Blacklist useless) should also be pretty trivial for him. Hm. You may want to think about installing that 30-meg "sister extension" in the right hand bar there.

Questions, comments, flames? Drop me a line at .


Revision History (SSL Blacklist)


4.0.32 (Jan-31, 2010)

  • Firefox 3.6 compatibility

4.0.31 (May-18, 2009)

  • Firefox 3.5 compatibility

4.0.30 (Dec-31, 2008)

  • Detect MD5 signature algorithms

3.0.25 (Nov-20, 2008)

  • Optional update: Firefox 3.1 compatibility

3.0.24 (Aug-12, 2008)

  • Parse and handle the odd-sized (1000-bit) RSA Data Security root certificate properly

3.0.22 (Jun-28, 2008)

  • Moved the blacklist database to a set of DNS servers for dynamic queries. Extension size reduction: 99.93%
  • FF3 compatibility: handle EV certificates properly

2.0.16 (Jun-23, 2008)

  • Expanded database covering x86, x64 and PPC platforms for key lengths 512, 1024, 2048 and 4096 bits (yes, this makes the extension ridiculously big at a 31MB download and 60+MB installation size)

1.3.15 (Jun-19, 2008)

  • UI fix for FF2 on Mandriva Linux (and possibly other distros)

1.2.13 (Jun-16, 2008)

  • Minor bugfixes
  • Icon in URL bar for secure sites
  • "Official" FF3 compatibility

1.1.10 (Jun-1, 2008)

  • Mac compatibility
  • Added one-click reporting capability

1.0.7 (May-28, 2008)

  • First release

Revision History (SSL Blacklist Local Database)


1.0.8 (Jan-31, 2010)

  • Firefox 3.6 compatibility

1.0.7 (May-18, 2009)

  • Optional update: Firefox 3.5 compatibility

1.0.6 (Nov-20, 2008)

  • Optional update: Firefox 3.1 compatibility

1.0.5 (Aug-12, 2008)

  • Optional update: added support for global install of the extension

1.0.3 (Jun-28, 2008)

  • First release