Rietta
Rietta.com Security
You are reading The Rietta Blog, a publication about the web since 2005.

Migrate Away From SSL/Early TLS for PCI Compliance

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.

Need Help?

Feel free to contact us for our security services if you are in need of assistance upgrading your current configurations.

About Brandon Dees

Brandon Dees' photo

Brandon Dees is a full-time Ruby on Rails developer on the Rietta team. Having worked with us since 2012, he has been pivotal in shaping our test driven development practices and shaping our remote pair programming practice that delivers solid, stable software time and time again.