September 14, 2012

Do Your SSL Certs Meet Microsoft's New Requirements?

Warning from Microsoft to the entire Internet: make sure that your digital certificates are at least 1024 bits. As of Oct. 9, 2012, longer key lengths are mandatory for all digital encryption certificates that touch Windows systems.

This means that Internet Explorer will refuse to access websites that do not have RSA keys with minimum lengths of 1024 bits. You won't be able to exchange encrypted emails, run ActiveX controls or install applications on Windows. This isn't new, as Microsoft started making announcements about this well over a year ago.

If your first reaction is "There goes Redmond bossing the rest of the world around again!", think about it. 1024-bits key length is already considered obsolete, so if you're hanging on to 1024-bit keys or weaker you're asking for trouble. The National Institute of Standards and Technology bulletin 800-57 recommends RSA key lengths of 2048 or 3072 bits. NIST calculates that 2048-bit keys will be good until 2030, and then they'll be easily breakable by brute force. 3072-bit keys have predicted lifetimes of "much longer." So 4096-bit RSA keys have lifetimes of "much, much longer."

Now What?

If you're running some Windows systems, start at RSA keys under 1024 bits are blocked. This tells you how to find weak keys and how to upgrade.

The rest of us must use other means. OpenSSL has a bunch of tools for querying SSL certificates. Use this invocation to get information on your local web server, and look for the following information:

$ openssl s_client -showcerts -connect localhost:443
Server certificate
subject=/OU=Domain Control Validated/OU=EssentialSSL Wildcard/CN=*
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=EssentialSSL CA
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA
Server public key is 2048 bit

You may test remote servers as well, substituting their URLs for "localhost." The example shows that the server's SSL certificate is verified by a commercial certificate authority, Comodo, that it supports the latest strong protocols TLSv1/SSLv3, and uses the very strong AES256 symmetric encryption algorithm.

You can query a mailserver the same way:

$ openssl s_client -showcerts -connect mailserver:995

Or an FTP server:

$ openssl s_client -showcerts -connect ftpserver:21

You'll have to know how your FTP is configured, because it varies. FTP/SSL is usually TCP port 21 or 990, and SFTP is usually TCP port 115, though sometimes it goes over TCP port 22.

Algorithm Confusion

A common point of confusion is the various encryption algorithms used by OpenSSL. In the above example the RSA key is 2048 bits, but the AES key is only 256 bits. The RSA key relies on an asymmetric algorithm. It uses a pair of encryption keys, one public and one private. The public key encrypts and the private key decrypts. You can fling any number of public keys into the world so that other people may send you encrypted messages, and you only need to keep track of a single private key to decrypt them. It's a clever way to easily to set up encrypted communications.

Symmetric algorithms require that both parties share the same key for encryption and decryption. This has obvious drawbacks, like figuring out how to securely share the keys, and like any secret when more than one person knows it, it's no longer a secret. But symmetric algorithms are efficient and don't need much computing power.

A typical SSL session is a busy little thing with all kinds of stuff happening, and it takes advantage of the different strengths of asymmetric and symmetric algorithms. The asymmetric RSA key allows anyone to establish an encrypted network session without having a pre-shared key, but at the price of significant CPU cycles. Once the session is established, new symmetric keys are generated and exchanged to encrypt the remainder of the session.

How the Internet Sees You

I love websites that let you test your servers, and there are a lot of them. Qualys SSL Labs has an SSL server test. Test your server and you'll see a report like Figure 1.

It goes on to give detailed information like supported ciphers, RSA key strength, supported protocols, and it even says if it's vulnerable to the BEAST attack.

What the Web Browser Sees

Web browser developers are getting stricter about the SSL information they display. In the olden days there was a little padlock at the bottom, and you clicked it to see the SSL information. Now they have multiple indicators. Chromium uses little colored padlocks, a plain page icon, and other indicators. Click on them to get full details.

Firefox is simpler and sterner. A gray globe indicates a mixed http/https page, a gray padlock is an https page, and only sites that pay mondo bucks for Extended Validation certificates get a green padlock. Firefox keeps changing their SSL indicators, so this could be outdated information tomorrow. For today, Figure 2 compares the same page in Firefox (on top) and Chromium. This page uses very strong encryption, but it still doesn't rate a splash of color in Firefox, just dull gray.

Upgrading Your Digital Certificates

I'm afraid I don't have a simple solution for querying or upgrading your digital certificates. Your upgrading method depends on whether your certificates are self-generated or from a commercial vendor, and how your public key infrastructure (PKI) is set up. How strong should you make them? You ought to do some testing before deciding, because the computational power required for higher encryption levels goes up steeply. So if you're thinking you'll, go for the gusto and use 4096-bit RSA keys and future-proof yourself forever, try it first and see how it affects server performance and user experience. The NIST thinks that 3072-bit keys should be good well beyond the predicted year 2030 lifespan of 2048-bit keys.

It's also a good time to check your own server configurations, and to limit who they'll accept connections from. The Apache Software Foundation has a great guide, Apache SSL/TLS Encryption that is useful not only for configuring Apache, but for understanding SSL/TLS.

Even though this is all a big pain, look at the bright side-- if you've been unsuccessfully trying to persuade your boss that you're years overdue to block SSLv1 and 40-bit symmetric keys, Microsoft might be doing you a favor.

Click Here!