Systems that handle payment information, particularly e-commerce systems, are regulated by PCI DSS. Changes to the PCI compliance requirements have reclassified the use of outdated and insecure versions of TLS (and its predecessor, SSL) as non-compliant. This has some significant impact across the software industry as the changes went into enforcement today, June 30, 2018. The key takeaways for us as web application developers are that we must ensure that our deployed systems are using modern and secure TLS configurations, and that we should now do so at the expense of supporting legacy web browsers that are non-compliant, namely old versions of Internet Explorer and Windows.
At Rietta, we are more concerned with providing strong protection technology for our customers than with achieving the minimum compliance that we can get away with, and accordingly, our recommendations are to use the maximum reasonable controls allowable based on your system’s business and user support requirements. For us, this sometimes means abandoning insecure legacy support as soon as it becomes a valid business option, and this is a case in point.
June 2018 Deadline for PCI DSS version 3.1 / 3.2 requirements
The PCI DSS version 3.1 published in April 2015 updated the requirements for securing transmission of data, originally with a June 2016 deadline. This deadline was revised to June 2018 based on industry pushback and kept in place in the PCI DSS version 3.2. Now the final deadline for this change is upon us, meaning it’s time to hurry up and comply if you haven’t already. It’s also a perfect time to review and revise your organization’s procedures for implementing, documenting and verifying TLS security.
Use TLS 1.2, disable fallbacks to weak versions
The basic changes that should be implemented and enforced for acceptable transport security are to ensure support is enabled for TLS 1.2 and better, applying known best-practices for secure cipher suite selection, and to disable fallback support for any version of TLS or SSL below 1.1. This will have the noteworthy side effect of eliminating support for Internet Explorer on Windows Vista or older, as well as versions of Internet Explorer on systems that do not enable TLS 1.1 or 1.2, which are not enabled by default for versions below IE11 on Windows 8.1 or greater.
SSL Labs Server Test is your friend
Qualys SSL Labs provides a free SSL Server Test which provides an excellent view into the details of your deployed TLS, with recommendations for what configuration details can be made more secure.
I believe it is also a great idea to schedule an automatic periodic report and enable notification of the relevant stakeholders whenever the results on this type of report change. We’re planning to experiment with some open source utilities to help us set this type of monitoring up in the near future, such as testssl.sh.
While you’re at it, review other TLS best practices and strengthen your systems even more
A lot of great progress has been made in recent years regarding TLS security on the internet. While you’re reviewing and updating your basic protocol support, consider also strengthening your security even more with some additional standard tools such as CAA, OCSP, DNSSEC, HSTS, Preload Lists, Let’s Encrypt, and CT Monitoring.