Insecure SSL and How PCI gets it right

Insecure SSL and How PCI “Nearly” gets it Right

Nearly every assessment project we do we see insecure ciphers. Unfortunately, many people see SSL and cryptography as a ‘voodoo art’ that mere mortals can not tackle, or they just assume that the default install of the web server will set it up just fine.

It would seem logical if the data transmitted to and from your site is important enough to encrypt, then you might as well do it properly. Afterall, large web sites don’t use encryption just for the fun of it, the mathematics required to undertake these cryptographic functions on a large scale requires significantly more CPU power, often including accelerator cards or dedicated SSL Accelerator appliances. This, of course, dramatically increases expense and infrastructure complexity, when comparing an SSL page to its non-encrypted counterpart.

Background

As some background lets define what exactly is an “insecure SSL Cipher”. For the sake of simplicity, it is probably best broken into two categories:

1. Insecure Cryptography. This is where the keys, signatures, and hashes that secure the data are weak and can be broken within a reasonable amount of time. Back in the mid-90′s, ‘export-grade’ encryption that moved from 40bit to 56bit in strength was really thought to be ok for general consumer transactions. It was generally thought to be strong enough to keep honest people out, and dishonest people would have to go through quite a bit of number crunching to break the keys. But in 1999, the Electronic Frontier Foundation (EFF) and distributed.net rocked the world and cracked a 56bit key in just 22hrs. Recent advances in video card processors and interfaces now makes the Graphics Processing Unit (GPU) an extremely fast and accessible math processor that is rapidly reducing the time it takes to crack passwords and of course cryptography of all sorts. For example, some software claim statistics like 200 million attempts per second at cracking md5. It is now generally recognized that keys should be 128bit and above in key length. Of course this is a generalization since each cipher’s strength varies even at the same key-length, but it’s a good rule of thumb.

2. Insecure Protocols. The protocol is essentially how the cryptography is used to secure the data. The protocol uses cryptography (keys, certificates, and hashes) to create and maintain a secure connection between the user and the server. If the protocol can be subverted, it can allow an attacker to tamper with the encryption mechanisms to reduce or eliminate it altogether. SSL version 2 is a great example of an insecure protocol, with quite a list of problems that would keep a mathematician awake at night.

The fix for the above problems is of course to disable the insecure ciphers and protocols at the server level. When a secure connection is being established, the server and the client (eg. the user’s browser) negotiate the protocol and encryption that will be used. If the server does not allow the insecure mechanisms then the client can not possibly setup an ‘insecure’ connection. Everyone should disable SSLv2 and all ciphers under 128bit.

You might be wondering how many people rely on SSLv2 for their transactions. Just how many people need to use SSLv2? There doesn’t seem to be a definitive resource that lists all the browsers ever created and what versions of SSL they support. However, doing some research I stumbled upon a site from the “Massachusetts Registry of Motor Vehicles” that really is good on several levels. This site does not appear to allow SSLv2 or insecure ciphers. It also defines what browsers will work with the site and tells the users how to set their browser settings if they do have problems. This site says that it will support Internet Explorer (IE) version 4 and above. This version of IE was released in 1997. Therefore only IE versions released before 1997 would not work with their site; that would require a user not to have updated their browser in nearly 12 years!

So how does this relate to PCI?

Well up until November 2008 there was quite a bit of ‘grey’ area in the wording of SSL requirements in the PCI standards (section 4.1). As with all standards, they are often quite general and open for interpretation. You might be surprised to know that there are some companies out there that want to do as little as possible to meet the certification criteria rather then do the “right thing.” Disabling insecure ciphers and SSLv2 seems easy, and indeed it is, but some companies would rather argue ad-infinitum that they might block one legitimate user from using the site instead of making the site more secure for everyone else to use. It would be much better to guide and nudge that one user to better protect themselves – a user typically has no idea what goes on behind the scenes and wouldn’t even know they are unsafe.

To combat this argument, in November 2008 (PCI Assessor Update Nov’08p1), the PCI council came out and said quite specifically that SSLv2 would create a failure in PCI compliance if it was used to transmit confidential information. To my absolute amazement they did not go so far as to say SSLv2 must be disabled altogether. They leave an ‘out’ so that supposedly an insecure browser can initiate an SSLv2 session so the user can receive an ‘error’ and be told to upgrade their browser. This is quite ridiculous because now the PCI assessor needs to look at the application business logic to ensure this mechanism is indeed in place, and is in place properly. The biggest real problem is that applications change. One small slip up and it is quite possible that a developer inadvertently drops the browser check and SSLv2 is enabled again for the entire site. The best way to solve the problem is never have SSLv2 enabled and to redirect from a non-encrypted site to the ‘secure site’. Use the non-encrypted site to provide directions in case a user needs help with their browser, just as MA-RMV did above.

In essence the PCI council “nearly got it right”. I have been considering why the council would allow SSLv2 just to throw an error to a user and I just can’t think of a valid use case. So this one ruling not only theoretically allows implementation of insecure protocols – since it doesn’t explicitly disallow them – but they also make it much more difficult for an assessor to determine just how SSLv2 is being implemented and caught.

If every single website on the Internet turned off SSLv2 right now, the world would be a slightly better place, and this discussion would end – as every user would have no choice but to fix their browser. Sometimes users need a little motivation to change; 12 years really is a long time not to have updated a browser.