PCI Blog - Compliance Demystified

SSL and PCI Compliance

For many merchants and service providers, the primary point of contact to customers is through a web page/service secured using an SSL connection. Of course, such a connection is emphatically in scope of the requirements of the PCI DSS; most obviously requirement 4 that covers the encryption of data transmitted over a public network.

Many people are unsure how to reconcile these requirements with the ‘export grade’ SSL encryption that were ubiquitous only a few years ago.

These ‘export grade’ encryption systems were the direct result of the US export restrictions on strong cryptography that classified such cryptographic systems as munitions, and therefore prohibited their export from the country. Fortunately, the restrictions around the export of cryptography has been significantly relaxed since the late 1990’s, with new legislation allowing licensed distribution to most international countries being passing in early 2000. Requirements for the licensing of cryptographic systems are still being updated.

This change in policy has resulted in the effective extinction of the ‘International’ version of the web browser - where the cryptography was deliberately dumbed down to an export compliant level.

So, what does all this mean for a web site trying to meet the PCI DSS requirements for strong encryption of cardholder data? The restrictions in this area have been relaxed for long enough that by enforcing only high level encryption on your web site, it is unlikely that you will be turning away any potential customers, regardless of the country they are from.

The next obvious question is how can I do this?

Of course, you can configure your web server to only accept ciphersuites that are compatible with the requirements (ie RC4 or better, with a secret key length of 128 bits or more - actually 112 bits for two key triple DES, if you want to be pedantic). In Apache this is done with the ‘SSLCipherSuite’ directive. I find it very useful to use the openssl ‘ciphers’ command to check which ciphersuites are enabled by any particular SSLCipherSuite directive, before going to the trouble of updating the webserver (eg, “openssl ciphers -v “ALL:!SSLv2″ will return a list of all ciphersuites, excluding all those from SSL v2).

Once you’ve got your webserver setup you can check it with an automated tool such as SSLDigger, or run through each ciphersuite by hand (eg by using a script, or by individually enabling each ciphersuite using the about:config interface in Firefox). My personal preference is to do things using my own tools/scripts, for reasons I will expand upon below.

So, how come many sites still appear to be using low grade crypto? Remember that the requirement is to secure cardholder data. There is no problem with enabling all ciphersuites - with high, low, or even no cryptography - and redirecting those customers whose browsers are not using compliant cryptography to another web page that does not put cardholder data at risk. This technique is used by many larger online sites, and is why I do not necessarily trust automated tools when testing SSL connections. A valid connection may not necessarily result in the ability to transfer cardholder data.

You can, of course, redirect the customer on a failed SSL connection request to achieve the same end. However, redirecting based on the type of connection provides the customer with the SSL connection they are expecting (lock icon, different colour address bar, etc).