Latest PCI guidelines cause headaches all around

In April 2015, The PCI Security Standards Council released its latest PCI DSS 3.1 requirements. Included in this document is a small paragraph that has lots of major implications…

Note: SSL and early TLS are not considered strong cryptography and cannot be used as a security control after June 30, 2016. Prior to this date, existing implementations that use SSL and/or early TLS must have a formal Risk Mitigation and Migration Plan in place.

Sounds like an innocent statement that states that very old technologies should not be used. Nothing could be further from the truth…

TLS 1.0 is affected

What the PCI Council has done is make TLS 1.0 a technology they do not allow for PCI compliance. The problem here is it is estimated that 20% of all traffic (source: Cloudflare) still uses TLS 1.0.

TLS 1.0 is used in Internet Explorer versions 8 through 10, Safari 5, and Android versions 3.3 or older.  There are still a good number of people using these older browsers and operating systems.

Disabling TLS 1.0 is sure-fire way to cut into sales, as those customers that can no longer shop on your site will go elsewhere…

Note: As far as I know, there have not been any real-world breaches that have occurred against TLS 1.0 directly. It is theoretically possible, but the work and time involved to hack TLS 1.0 makes it a very unlikely target (as opposed to social engineering a password to the servers themselves).

Servers are affected

Adding fuel to the fire is the fact that server operating systems such as Red Hat Enterprise Linux 5 (and its clones) can not use any SSL higher than TLS 1.0. Even though RHEL 5 is not end of life until late in 2017.

This means that if payment gateways stop supporting TLS 1.0, thousands of server across the internet will not be able to submit payments…

We have an open support case with Red Hat on this issue, as some of our legacy servers would be affected.

What’s a merchant to do?

For now, if your PCI scanning company flags TLS 1.0 on a quarterly scan, you can (and should) submit an exception providing the PCI scanner with a mitigation plan. This will delay any action until June 30, 2016. We have a template we can provide you for making this exception request easy to do.

I think some of this may change as time goes on, so for now, sit tight, submit the mitigation plan, and keep on conducting business as usual…

 

Looking for a web host that understands ecommerce and business hosting?
Check us out today!

One Comment

  1. Bernd P says:

    For my Opinion something is wrong with the feel for “Maximum Security”.
    As far as it is known that TLS 1.0 is at least in danger to be vulnerable if not properly patched/mitigated or in case if weak Suites are in use, it makes no Sense to further allow this potentially insecure Protocol Version.
    So, the most modern Protocol we have, IS TLS 1.2 and thus to be the Standard for now. Since PFS can only be properly supported on TLS 1.2, this is the next Target to reach ASAP, means by removing old non-PFS Suites from any possible Server. Immediately. PFS is already supported in all modern Clients. Older ones or old Devices w old OSes are – per Definition – unsafe to use and therefor should no longer be enabled and not allowed to be used.
    Servers that cannot be upgraded/patched, are simply and unluckily Subject to be removed and replaced by newer ones. I consider it irresposible to even “tolerate” the use of potentially insecure Configurations, Suites w/o PFS, TLS 1.0, Non-HSTS Policies for another two Years. The harshest Cut is the best Cut. In the Name of Communication Security and Privacy. And also regarding that TLS1.3 is already on the Draft Sheets!. Which is even a far better Concept bc really strict. So, working towards these Edges as soon we can and already now is the best Concept for secure Server Operations already today. Lethargy or “comfortable Slowliness” concerning Security Implementation is no Concept. Every additional TLS1.0 Day is a bad Day. Potentially a Risk. And this is enough Reason. And IF exploited the one or the other Day, by someone, it becomes a Catastrophy. Tighten your Systems.
    “Bullet-Proof” like Ivan Ristic says. Now! And not after another two Years!

Leave a Reply to Bernd P