24

My company is receiving this message causing us to fail our TrustKeeper PCI compliance scan:

Note to scan customer: This vulnerability is not recognized in the National Vulnerability Database. TLS v1.0 violates PCI DSS and is considered an automatic failing condition.

According to: http://en.wikipedia.org/wiki/Transport_Layer_Security

TLS 1.1 is disabled by default in IE10, and is not available at all in older versions. We have a good sized IE audience.

Does that mean all of our users with TLS 1.1 not enabled or supported at all will no longer be able to use our website if we make this change? This seems so soon. Am I missing something? All of our traffic is served through a load balancer, would it be possible to display some sort of message for those who don't support TLS 1.1?

Castaglia
  • 560
  • 8
  • 19
sam_so
  • 241
  • 1
  • 2
  • 4
  • 3
    You might not want to hear this, but it would be good if end users finally upgrade their browsers so everyone can kill old browser support. Or at the very least have another supported browser. – munchkin Apr 30 '15 at 01:35
  • On Windows you can enable schannel logging and look at the number of connections using TLS 1.0. We did this and saw a surprising 40% of connections to our sites being made using TLS 1.0 therefore we appealed on business grounds and this was accepted. Hopefully in the next 12 months this drops significantly or we are going to face a touch decision to cut off a lot of users. – CarlR Jun 18 '15 at 16:44
  • So, I read the answers but I'm still confused. If the deadline was pushed back to 2018, then why is it a fail? A warning, I could understand, but not a fail. – John Roa Feb 01 '16 at 19:28
  • @munchkin - and as of now, Microsoft thinks the same, no more security updates for anything earlier than IE 11. – Fiasco Labs Feb 01 '16 at 20:01

3 Answers3

22

Short version:

Long version:

PCI DSS 3.1 was released two weeks ago, on 14 April 2015. It lays out that

SSL and early TLS are not considered strong cryptography and cannot be used as a security control after 30th June, 2016.

In December 2015, the date for migrating existing applications was pushed back two years:

The Payment Card Industry Security Standards Council (PCI SSC) is extending the migration completion date to 30 June 2018 for transitioning from SSL and TLS 1.0 to a secure version of TLS (currently v1.1 or higher).

These dates provided by PCI SSC as of December 2015 supersede the original dates issued in both PCI Data Security Standard v3.1 (DSS 3.1) and in the Migrating from SSL and early TLS Information Supplement in April 2015.

As I understand it, "new applications" must still be implemented in line with the new requirement of 1.1+; the extension only applies to existing applications that used TLS 1.0 prior to April 2015.

The definition of what "early TLS" means is the subject of fascinated debate among QSAs, but it's safe to say 1.0 is part of it (and 1.1? Could be! Wait and find out!). (Update - as of December 2015, 1.1 is still "safe")

Here's how TrustWave says they're implementing these guidelines:

  • New implementations must use alternatives to SSL and early TLS.
  • Organizations with existing implementations of SSL and early TLS must have a risk mitigation and migration plan in place.
  • Prior to June 30, 2016, Approved Scanning Vendors (ASVs) may document receipt of an organizations risk mitigation and migration plan as an exception in the ASV Scan Report (in accordance with the ASV Program Guide).
  • Point of Sale (POS) or Point of Interaction (POI) devices that can be verified as not being susceptible to all known exploits of SSL and early TLS may continue to use these protocols as a security control after June 30, 2016.

So, if it's a new application, you might have to remove TLS 1.0 support. If it's not, push back on TrustWave and find out what sort of a "risk mitigation and migration plan" they require.

(Pulling the link from @mti2935 up out of the comments, here is Trustwave's Risk Plan Template. Thanks @mti2935!)

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • Are the payment gateways also going to remove TLS 1.0 connections? (i.e. Auth.net, PayPal, etc...). If so, this will impact a lot of sites hosted on server running centOS 5 / RHEL 5, which does not support TLS 1.1 or higher at all... – Rob Mangiafico May 01 '15 at 02:25
  • 1
    @RobMangiafico they'll have to by 30 June 2016... this is a dramatic and possibly even traumatic change. But I'm sure Red Hat will upgrade RHEL 5 openssl enough to support TLS 1.2 to answer the business need of their PCI customers. – gowenfawr May 01 '15 at 10:30
  • 4
    See https://www.trustwave.com/Resources/Library/Documents/PCI-3-1-Risk-Plan-Template/ for info on how to create a `risk mitigation and migration plan` – mti2935 May 03 '15 at 22:34
5

PCI DSS does prohibit TLSv1.0. No you wont be able to show a message to TLSv1.0 users without violating PCI DSS, because showing a message to end users means you have to finish TLSv1.0 negotiation. Technically its possible to configure the server side script to check the SSL enviroment variables for TLSv1.0 and show a error message in that case, but thats not allowed per PCI DSS.

It does not matter if you finish the negotiation for the purpose of accepting credit card data or if you finish the negotiation for the purpose of showing a "please upgrade your browser" message. Mere accepting or offering SSv2, SSLv3 or TLSv1.0 is prohibited at all.

Since the PCI DSS scan is automated, and fails at the negotiation state, it wont even matter if you push a HTTP 403 upon detecting a TLSv1.0 Connection.

However, I can say that IE10 users are very few. IE10 is shipped with the old Windows 7 media, and those are in most cases upgraded automatically through Windows update. Those users you have to struggle with is IE8, that is from Windows XP, and IE9 that is maximum available on Vista. Those on Windows 7 and later do have IE11.

sebastian nielsen
  • 8,779
  • 1
  • 19
  • 33
  • But what about Android 2.3 to 4.3, Safari 6 or older, etc... http://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers Combine this with IE 6-10, and it could impact sales by as much as 7-8%... – Rob Mangiafico May 01 '15 at 02:24
  • About Android 2.3 to 4.3, users cannot normally upgrade those anyways, because the manufacturer does often stop supplying updates to EOL devices. Best for the OP is simply to disable TLSv1.0 in his webserver, and those that dont support TLSv1.1+ will get an error simply. – sebastian nielsen May 01 '15 at 19:01
  • 2
    The old Android users can download Chrome from the playstore and it will work with TLS1.2. – Bad Dos May 04 '15 at 19:07
0

Run the checks on the http side.

First Site

http://secure.example.com.

This checks the browser and throws an error if there is no support. Otherwise redirects to the secure site.

Second Site

https://secure.example.com

The second site is the PCI server that supports what you need. It's the one you scan.

If the user hits this site directly, their session will fail. There isn't much you can do to give the user feedback. Make sure all your links point the user to http://secure.example.com.

Challenge

If the user somehow copy/pastes a link to the secure site, they will still not get notified. However, if they navigate to the secure area normally, they should have no issue.

Jonathan
  • 2,288
  • 13
  • 16
  • 3
    This is not permitted aswell since as of PCI DSS 3.0, a site which links to a off-hosted credit card application is also subject to PCI DSS Controls. This because if someone on "validate.example.com" would change the link to "secure.example.org" to instead link to "somebadhost.phishing-site.com" then credit card data is at risk. Thus also validate.example.com is subject to PCI DSS Controls. To gain out-of-scope for a application, the PCI zone must be completely unaffected if the application in question is completely taken over by a attacker. – sebastian nielsen Apr 29 '15 at 13:14
  • 1
    @sebastiannielsen thanks - completely changed the answer. – Jonathan Apr 29 '15 at 22:18