Hidden by all of the news about v3.1 of the PCI DSS being published, is a notice that was sent to all PCI approved scanning vendors (ASV) from the PCI SSC regarding how to handle SSL and “early TLS” vulnerabilities.
In regards to the “early TLS” comment, the Council did define the term by referencing everyone to NIST SP800-52 rev1. That NIST document essentially tells the reader that while TLS 1.1 is allowed, whenever possible, TLS 1.2 should be the only version used. In fact, NIST is highly recommending that all government entities move to TLS 1.2 by January 1, 2016.
FYI TLS 1.3 is in a draft specification by the IETF as we speak. I would expect that we will see TLS 1.3 released by the time the PCI SSC’s June 30, 2016 deadline.
With that covered, what is an ASV to do with a scanning customer’s SSL and TLS 1.0/1.1 issues?
According to the letter sent to the ASVs:
“Prior to 30 June 2016: Entities that have not completed their migration should provide the ASV with documented confirmation that they have implemented a risk mitigation and migration plan and are working to complete their migration by the required date. Receipt of this confirmation should be documented by the ASV as an exception under “Exceptions, False Positives, or Compensating Controls” in the ASV Scan Report Executive Summary and the ASV may issue a result of “Pass” for that scan component or host, if the host meets all applicable scan requirements.”
The key here is that you must be mitigating the vulnerability and working to migrate to TLS 1.2.
So what would a mitigation plan look like? Most likely you would monitor for usage of SSL or TLS 1.0/1.1 connections to your devices that only support SSL and TLS 1.0/1.1.
For those of you that are not going to be able to migrate to TLS 1.2, the Council gives ASVs guidance there as well.
“After 30 June 2016: Entities that have not completely migrated away from SSL/early TLS will need to follow the Addressing Vulnerabilities with Compensating Controls process to verify the affected system is not susceptible to the particular vulnerabilities. For example, where SSL/early TLS is present but is not being used as a security control (e.g. is not being used to protect confidentiality of the communication).”
The reason the Council has to be able to provide a solution past June 30, 2016 here is that it is my understanding that a lot of comments were received about “baked in” SSL that was going to require wholesale replacement of devices to correct the problem. A lot of those devices are IP-based point of interaction (POI) devices. ASVs have been instructed on the process to use to reduce the CVSS so that the vulnerability is no longer considered “high”.
If you have any further questions regarding this announcement, I would discuss it with your ASV. As with all things PCI, every ASV will have variations based on their own risk adversity as to what this pronouncement says.
PCI Guru 
Is my testing of Discover Card and Amex sites correct in that their payment sites allow TLS 1.0? I don’t mind moving to TLS 1.2, but I don’t want to be a first mover and suffer the customer complaints. The card sites should pave the path.
Good luck with that. The card brands are “special”. Unfortunately, your organization needs to do what the Council says and not look to the brands to be an example.
We have determined that a little less than 10% of our users would be impacted by turning off TLSv1.0. This is spread across old browsers and browsers that support 1.1/1.2, but do not have it turned on (I’m looking at you, Microsoft). Through additional testing with virtual browser tools, we have found that switching from old browsers to the latest versions of Firefox, Chrome, or Opera fixes the issue, regardless of the underlying OS. An old Android 2.2.3 smart phone, with the latest version of Firefox installed, works just fine. The lone platform we see no way of supporting is the first generation Amazon Fire tablet. Amazon provides no software upgrade to gain TLS1.1/1.2. Our plan is to test for TLS version, and prompt users with TLSv1.0-only to upgrade their browser, or, if they have the ability, activate 1.1/1.2 in their browser. I agree, it’s a moving target, and it always will be.
Real life – since we turned off tls 1.0 last week, we have a 10 to 100 time increase in customer complaint volume. IE seems to be the culprit. Our customer support staff is now walking customers through the IE configuration or telling them to use FireFox. Older XP and Mac customers simply cannot buy anything. What a total sh!tshow. I can kiss any raise or promotion goodbye. I wish our security guys would have pushed back with the QSA. No way any business who relies on ecommerce revenue should implement. Wastes our labor, frustrates customers – DO NOT IMPLEMENT!
Sorry, but you should ALWAYS test things before you shut them off. You are not required to stop using SSL and Early TLS until June 30, 2016. However, most organizations are turning it off on their external facing Web sites as soon as they can. Obviously, this was not possible for your organization. You can turn things back on, but then be prepared to have a compensating control worksheet (CCW) written up that explains what you are doing to mitigate the use of SSL and early TLS.
I am in an industry where there are a large number of Kiosk type systems that are still running Windows XP. However, the majority of those systems are out of our control, not owned by us, and are unlikely to be upgraded. That said, we will have to continue to support those systems. Which means I will have to continue to allow TLS1.0. What recourse would I have with the ASV/QSA in this situation. Also, I used to work in the banking industry and I can guarantee that the majority of the ATMs in use in the US are still running Windows XP.
It is all in the version of XP that is being used. XP Embedded is still supported through 2016 although a lot of kiosks and ATMs were running the full version and not the embedded version. That said, you need to confirm what version of XP is being used in the kiosks and ATMs.
You have a valid business use case to justify your support of TLS v1.0, so you will need to document that case and present it to your ASV to get them to remove the fail due to using an insecure protocol. You would use the same document for your QSA to justify the use of TLS v1.0. I have a number of clients in the same boat and that is how we were instructed by the Council to handle it.
TLS 1.0 for ecommerce is needed and this move by the council is not well thought out as others have noted. The fact that you ARE getting scanned by an ASV that could easily detect if your TLS 1.0 installation is configured poorly and hence insecure. Blocking a large number of customers because your site only supports TLS 1.2 is not the answer and you’ll see the big boys will be the last to do so which is exactly the reasoning given for making this drastic change.
We need less knee jerk reactions in the security side of things if we expect the problems to be addressed and not just the minimum checkbox reactions you are going to get.
You might be surprised about your “big boys”. I work with a number of them and they have all in the last few weeks ditched everything but TLS v1.2 and say they are doing fine. They all report a spike at the transition in customer calls/messages regarding access to their sites, but not a torrential flood of support issues. That said, a number of them operate worldwide and for their foreign sites they have kept TLS v1.0/1.1 and even SSL v3 because of the significant user bases that need those protocols, particularly for parts of Asia, Africa and Eastern Europe. Those with foreign sites are expecting to have a lot of fights with their ASVs over “failed” scanning results due to the fact that they are running these “insecure” protocols.
https://www.ssllabs.com/ssltest/analyze.html?d=paypal.com&s=66.211.169.66
https://www.ssllabs.com/ssltest/analyze.html?d=amazon.com&s=176.32.98.166
https://www.ssllabs.com/ssltest/analyze.html?d=www.walmart.com&s=23.33.253.194
Not sure what big boys are you referring to either, but the top alexa ecommerce websites do run TLS1.0 and some sadly still even use RC4.
I did not say ALL big dogs, only some. LOL!
Is the PCI council saying my connections to amazon are insecure? What exactly is the problem with tls 1.0 / 1.1?
They are also affected by POODLE. However, there is a new issue with SSL/TLS called FREAK (https://freakattack.com/) that was announced back in March 2015. That adds insult to injury with TLS. If you read the literature on POODLE and FREAK, they are more likely to be successfully attacked internally than externally.
Ok, but freak when you have export grade decryption available and poodle is long patched for. What are the problems with Tls 1.0 and 1.1. poodle even affected 1.2. I’m looking for the technical reason why he protocols are broken and why this is coming up. Export grade encryption you just turn off and poodle yo patch for,
Agreed. But not everything you can just turn off in every situation. A lot of software and appliances have SSL and/or TLS baked in. See my latest post https://pciguru.wordpress.com/2015/05/25/ssl-and-tls-update/
I totally get that. But if TLS 1.0 is secure in a particular configuration, why is PCI council making us turn it off to pass a ASV scan? TLS 1.2 even has problems if you don’t configure it correctly (i.e., with CBC ciphers).
Because not all organizations understand the nuances, so to be safe the Council is calling a halt to everything. Yes, it is a “throw the baby out with the bathwater” approach, but it will keep everyone safe. If your ASV is failing you on TLS and you have a valid argument, then you should make that argument with your ASV. If they refuse, then maybe you need a new ASV.
The throw the baby out with the bath water approach is *exactly* the wrong approach and demonstrates what is wrong with the field of info sec today. We focus on ‘compliance.’
Requiring people to turn off secure protocols damages the validity of the PCI program and is already viewed as compliance for compliance sake, rather than working to make everyone safe.
Don’t forget that Red Hat Enterprise Linux 5 (and its derivatives like centOS 5) which is not EOL until 2017 also do not support anything higher than TLS 1.0. If gateways turn off TLS 1.0, thousands of websites will be unable to process any payments to say the least…
So Red Hat and company will likely need to fix their situation with TLS then will they not?
Could you offer some advice on this?
The important thing about TLS 1.0 is that it’s the best mechanism supported by Internet Explorer on Windows XP. Thus disabling it will cut off IE8 users on XP. IE8 XP compatibility is also the reason why the CBC cipher is still allowed.
From what I can tell, NIST SP800-52 rev1 takes this into account and allows TLS 1.0 for interoperability with non-Federal networks as long as it’s not possible to downgrade connections to SSL 3.0 (section 1.2, paragraph 3).
But our ASV is saying that TLS 1.0 is not allowed at all but they also say that CBC is still allowed. This doesn’t really make sense, does it? If the council’s intention is to cut the cord on XP then why not take out CBC as well?
Thus to me it seems like TLS 1.0 should still be allowed. What are your thoughts?
Really? You allow a system running IE8 to connect to your network? I know of very, very few organizations that are still running IE8 on XP.
ASVs do not have a lot of choices in the matter. Once the CVSS score for POODLE was calculated above 4.0, all of the vulnerability scanners started flagging it as “high” and therefore a fail on the ASV scans.
We went through this years ago with the banks and securing online banking. The bankers swore that their customers would drop them if they dropped support for all but SSLv3 and TLSv1.0+. Guess what? Nothing happened. Customers that did have an issue, upgraded their browser and the world moved on.
So, here we are again. If you look at the exploit, it’s much more exploitable internally than externally. However, most merchants dropped SSLv3 on their external sites like a hot potato, particularly once the PCI SSC announced that it was no longer considered secure. A lot of them are in the process of dropping “early TLS”, aka TLS v1.0 and v1.1 as well. It turns out that it’s just easier to drop it because most online customers are savvy enough to be running current software these days.
There is an out for organizations that requires working with their ASV through June 30, 2016 to mitigate and migrate. So, it’s not like we got cut off cold turkey.
A good chunk of the NHS is still on XP/IE8.
The council’s recommendation is basically just “use 1.2 if you can”. But 1.2 is not a panacea and was also exploited by POODLE (in fact all of the recent exploits have been attacks on ciphers not protocols).
The POODLE exploit needs to be detected by pen testing and the council just recommending version numbers is not a solution. By merely saying “1.2 good, 1.0 bad” they are simultaneously not protecting anyone and throwing the baby out with the bath water.
Honestly it’s not a problem for us as we can turn off 1.0 in two clicks. I just don’t think the council’s reasoning makes sense.
Agreed. But you also cannot have people just sit on their hands and do nothing. YOu likely would have pilloried the Council if they had cone nothing. So the Council cannot win regardless of what they do.
For the vast majority of organizations, the only thing they can do is to transition to TLS v1.2 because it is the only thing they are capable of doing.
I looked into it a bit more yesterday and IE8/XP is the least of our worries. Worst case scenario is that 95% of Android users and 25% of Safari OSX users don’t support TLS 1.1 or 1.2, but realistically it’s probably more like 50% and 1% respectively. IE8-10 on Windows Vista/7 is a real wild card because while they support both 1.1 and 1.2 I don’t think Microsoft have turned them on by default yet (their POODLE fix only turned off SSL 3.0 I think?).
CloudFlare also say that 20% of traffic to their network doesn’t support 1.1 or 1.2 which about lines up with these guesstimates.
It seems like basically any client that supports 1.1 also supports 1.2 and you end up with a big divide of 1.0 and 1.2 clients. You could probably safely turn off 1.1 today but I think everyone should stall on 1.0 until Microsoft, Apple, and Google more aggressively push out updates.
Most of those Android users are due to the fact that their cell carrier and/or smartphone manufacturer has bailed on their phone and is no longer doing upgrades. I’m surprised at the Safari users though. Apple has always prided itself on being ahead of the curve, so the fact that TLS v1.1/1.2 aren’t supported is surprising. I think you’re correct about Microsoft, but I have no other sources to confirm your statement. That said, it was my understanding that Google is only using TLS v1.2 for securing their searches.
Windows XP has been out of support for over a year, and even that was drawn out longer than the standard lifecycle. Unsupported operating systems are not allowed by the DSS, so any reason for compatibility with Windows XP in the context of the DSS disappeared a year ago. There are GNU/Linux distributions still supported by their vendors using versions of OpenSSL that only support up to TLS 1.0, but most these days support upgrading from one release to the next, so that isn’t really a defence either.
CBC mode ciphers are “okay” with TLS 1.0, unless the implementation does the padding incorrectly (the TLS version of POODLE). BEAST has largely been mitigated client side in browsers (we’re not counting unsupported browsers). TLS 1.1+ also supports the CBC mode ciphers, and has some band aids for the known attacks. It’s a very good idea to move away from CBC to the AEAD ciphers if you can, but until a another attack on CBC mode ciphers in TLS comes to light I would not classify their use as high risk. This post from 2013 has a similar assessment of BEAST: https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat
TLS 1.0 *is* allowed until June 30, 2016, but there must be a “Risk Mitigation and Migration Plan” to move to later TLS by that date. When the plan is submitted as evidence to the ASV they should add an exception to the report (unless it fails to cover the points in the “Migrating from SSL and Early TLS” information supplement), so it would then pass. However, if RC4 ciphers are used (the CVSS score for this was raised recently, making it a fail), or the system is affected by another vulnerability such as POODLE, it can still fail.
Be very careful about your generalized statements about Windows XP. XP Embedded is still supported through 2016, so not all versions of XP are no longer supported. Only the familiar desktop versions are the ones that went out of support. And even then, I have numerous clients that bought the extended support agreement from Microsoft and still have supported XP (for a price).
I agree with your analysis of the POODLE situation. However, most people have no idea as to how to implement your suggestions so most organizations are just migrating to TLS v1.2 to be safe.
Maybe it is too early in the AM for me to be thinking about this stuff; but in what PCI compliant scenario would a POI device be on the Internet listening on port 443 where an ASV would spot this and call it out?
I have a lot of small franchisee clients (4 to 20 retail outlets) that have IP-based POI going straight out through their firewalls over the Internet to their processor. Those are in-scope for ASV scanning.