SSL Blacklist 4.0
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.
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