A lot of organizations are finding out that just turning off SSL is just not an option. This is particularly true of merchants running eCommerce sites predominantly used by mobile customers or customers running older operating systems. To the surprise of a lot of IT people, it turns out that most mobile browsers do not support using TLS. And while most Western PC users have reasonably current browser software, the rest of the world does not and turning off SSL will remove a significant portion of some merchant’s customer base. As a result, for some organizations going “cold turkey” on SSL is just not an option without suffering significant consequences.
But there is a larger problem with SSL lurking inside almost every data center. That is with appliances and data center management software that have SSL baked into them for their Web-based management interfaces. A lot of vendors availed themselves of OpenSSL and other open source SSL solutions to secure communications with their appliances and solutions. To remediate these solutions, an organization might be lucky enough to upgrade the firmware/software. Unfortunately, a lot of organizations are finding that replacement is the only option offered by vendors to address these situations.
The bottom line is that because of these situations, SSL and early TLS will not be addressed by just disabling it and moving on. As the PCI SSC found out when they asked Qualified Security Assessor Companies and Participating Organizations about what it would take to address the SSL/early TLS situation, they were told about these issues and therefore set a deadline of June 30, 2016 to provide time to address these situations.
While organizations have until June 30, 2016 to address SSL and early TLS, that does not mean an organization can just sit by and do nothing until that deadline. Here are some things your organization should be doing to address SSL and early TLS if you are unable to just turn it off.
- Get a copy of NIST Special Publication 800-52 Revision 1 titled ‘Guidelines for the Selection, Configuration and Use of Transport Layer Security (TLS) Implementations’. This publication is the Bible for how to minimize and mitigate the risks of SSL and early TLS.
- Identify all instances of where SSL or TLS are used and versions supported. It is not just those instances that need to be remediated, but all instances. The reason is that TLS v1.3 is in draft specification and its release is likely just around the corner in 2016. That is why a complete inventory is needed so that when TLS v1.3 is available you will know what remaining instances will potentially need to be updated, upgraded or possibly even replaced.
- Implement TLS-FALLBACK-SCSV to minimize the chance of SSL/TLS fallback. This option was developed to address the issue created by POODLE. However, be aware that only certain versions of browsers support this option, so it is not a perfect solution.
- Monitor your external Web sites for SSL and early TLS usage. Track statistics of how many sessions are using SSL or early TLS so that you can determine usage of those protocols and therefore know the actual impact of any decision regarding those protocols. These statistics will also allow you to know when you might be able to pull the plug on SSL and early TLS with minimal impact.
- Modify any external Web sites to present a message to anyone using SSL or early TLS to warn them that you will be no longer supporting SSL/early TLS as of whatever date your organization chooses to drop that support.
- Where possible, configure the Web site to only use SSL or early TLS as the absolute last resort. Unfortunately, a lot of vendors modified their SSL solution to not allow this sort of change so do not be surprised if that does not become an option.
- Develop a migration plan for your remaining instances where SSL or early TLS are used. Contact vendors involved and document what their plans are for dropping SSL and early TLS.
- Be prepared to create compensating controls for SSL and early TLS that you will not be able to remediate by the deadline. Unfortunately, I have a sneaking suspicion that some vendors will miss the June 30, 2016 deadline as will some merchants be unable to turn off SSL by the deadline. As a result, those organizations will have to put compensating controls in place to maintain PCI compliance. These compensating controls will likely be messy and complex as enhanced monitoring will likely be the only controls available.
PCI Guru 
For data center systems management appliances do not login to them from the Internet. Turn off their IPs and inbound ports at the edge firewalls. Instead 2-factor into a data center beachhead and login to the appliances via an RFC 1918 IP address.
Agreed if you are doing remote access. However, the PCI DSS is also demanding turning off SSL and early TLS internally as well which a lot of appliances use for their Web-based management interfaces.
I find it strange that the council is being so strict on this issue whereas other areas are left wide open but could be closed with little knock on affect.
Particularly I’m thinking of VOIP where a lot of small companies pay for a virtual switchboard from online services. Most of these services don’t offer TLS and apparently this is totally fine with PCI compliance. The problem is that the council only says that the switchboard itself has to be secure and outsourcing it to a third party and connecting to it remotely over an unsecured connection is out of scope. Yes, this is exactly the same as POTS but if websites all need to be TLS 1.1+ then why not phones too?
VoIP is a very interesting situation. The reason is that most networking personnel and QSAs are clueless as to how VoIP works. As a result, VoIP tends to get treated like plain old telephone service (POTS) and not what it is which is an IP-based application. Therefore, if the outsourced VoIP system is in scope for PCI, then that connectivity to the outsourced VoIP system needs to be over TLS 1.1+ and not SSL or early TLS. See my post on VoIP and PCI Compliance – https://pciguru.wordpress.com/2011/06/07/voip-and-pci-compliance/
The problem is that most VoiP providers consider themselves “Telecommunications Providers” which the council specifically calls out as out of scope. Even if you want to use TLS, good lucking finding someone who offers it to small businesses.
Oh, and we’ve had plain old SSL and RC4 disabled on everything Internet-facing for over a year without a single complaint. I don’t think SSL will be the issue, it will be killing off TLS 1.0.
These are the devices and combinations we’ve found that do not support TLS 1.2 with out-of-the box configurations:
Internet Explorer pror to v9. IE 9 and IE 10 do have TLS 1.2 capability on Windows 7 but it is turned off by default.You have to go into Internet Options – Advanced tab and, it kills me to say this, “Check the box.” If Microsoft does a forced upgrade to IE 11 to support their Jan. 12, 2016 support deadline, this becomes a moot problem for consumers.
IE 9 on Vista does not support TLS 1.2 because Vista does not have it in the operating system. XP does not support TLS 1.2 either.
All of the above can be mitigated by using Firefox or Chrome because they do not rely on the operating system for their encryption capabilities.
Android prior to v4.4, KitKat. This will affect tablets more than smartphones because tablets tend to have more longevity. The Gooogle Developers Dashboard at https://developer.android.com/about/dashboards/index.html shows 37% of Android devices are still using a version of Android prior to KitKat. This also can be fixed by just installing and using Chrome instead of the built-in browser.
Red Hat Enterprise (and CentOS) prior to v6.5. Because OpenSSL is a core part of the operating system it cannot be upgraded. There are some hacks to install a later version of OpenSSL and hook it to Apache but that probably isn’t woth the hassle.
Windows Server 2003 and Windows Server 2008 (the original 32-bit version). http://blogs.msdn.com/b/kaushal/archive/2011/10/02/support-for-ssl-tls-protocols-on-windows.aspx
With Windows Server 2008 R2, SSLv2, SSLv3 and TLS 1.0 are the default ciphers. Registry changes are needed to disable SSLv2 and SSLv3 and to enable TLS 1.2, but the capability is there, once the changes are made and the server is rebooted.
Too many so-called “appliances” to mention, including several that typically are Internet-facing such as SMTP servers and load balancers. One notable issue we hit was with the Cisco IronPort. We don’t use it but several business partners do. After we upgraded our SMTP servers a year ago to the then-current version of OpenSSL, we could not establish SMTP TLS connections with some partners. Cisco’s AsyncOS had a bug that prevented it from working with newer versions of OpenSSL. That bug was fixed in v8.02 but we learned some partners were way behind in updates.
Mac OSX prior to Mavericks.
Apple iOS has supported TLS 1.2 since v5.
We’re still seeing between 8% and 12% of consumers connecting with TLS 1.0 despite our having prioritized the TLS 1.2 ciphers (financial services industry). That’s per unique source IP address and has not changed in five months. We’re hoping the semi-mandatory upgrading of people to Windows 10 as well as the upcoming holiday gift-giving season will reduce those numbers. TLS 1.1? Pffft. Like 0.1% of people.
But if we still have the same percentage at the June 30th deadline, we, and I suspect other companies, will opt to fail the ASV scan. No company anywhere will arbitrarily cut off 10% of their customer base from making purchases just because some people somewhere decided to draw an arbitrary line in the sand. This would be proof that security inhibits the business.
Yeah I’ve brought up these issues before and it’s playing out exactly as expected. Android in particular is dire. Unrelated to PCI but I’ve already had complaints from customers in poorer countries (Brazil) because we used SSL SNI at one point which isn’t supported by Android 2.x. The Guru often says that banks had no problem killing off IE6 etc but banks rarely operate outside of their (first world) home market so it’s apples and oranges.
I have to concur with your comments. I work with a number of clients that have customers world wide and they are struggling with killing off SSL and early TLS. While it can be readily killed in the US and Europe, other parts of the world need SSL and early TLS. In all likelihood they will need to have a compensating control in place after June 30, 2016 because of this situation in other parts of the world.
There’s really no teeth in PCI-DSS until you have a breach and then you’re always found to be non-compliant anyway. And if you’re big enough and generate enough in swipe fees for the card brands, they’ll never cut you off. If the Council continues to ignore the business impact, I suspect people are going to thumb their nose at the Council even more.
SET CYNICAL MODE ON. Why should Level 3 and 4’s even care if they’re compliant? What’s going to happen if they’re breached? Get spanked because they lied on the form? As long as they’re not found negligent in a court of law, they saved a boatload of personnel time and money by lying. And since it’s a target-rich environment, chances are they’re not going to be the one who gets hit. SET CYNICAL MODE OFF.
Unfortunately, it is the Level 3/4 merchants that are now being targeted because they are easy targets for just the reasons you imply. You just do not hear about it like you do when Target or Home depot are breached. If you subscribe to Data Breach Today or similar you would see that every day there are numerous breached reported that are small to mid-sized organizations. And those are the ones reported. There are tons that go without any reporting in the media.
I was at a security conference a few weeks ago and the keynote speaker was talking about issues like these and said “and God help you if your company is still using IE 8.” A table near me was full of name badges from one of the largest banks in the USA and they all looked at each other and snickered. I know some of them and asked “Really?”. He said they had a fair number of in-house applications that would not work with any version of IE beyond 8, including some of their online applications. He said they had to roll out Chrome in addition to IE 8 so their own employees could use their own applications to support customers. SDLC? “Write once and run forever”, apparently.
I know of a number of large organizations that have applications that are only compatible with IE8 so that situation is not as rare as you might think. But your statement of “write once, run forever” is exactly how their business users think. The business does not want to pay for upgrades for an application that runs just fine. That is why I am seeing a few organizations bailing Microsoft-centric servers and heading back to mainframes and Sun/HP Unix solutions. They want to get back to not having to invest so much in hardware/software upgrades/maintenance as well as have bulletproof, powerful, reliable platforms.