Tuesday 6 March 2018

The PCI Security Standards Council has set a deadline of 30 June 2018 for websites to comply with new security measures if they want to maintain PCI certification.

RedShield is committed to helping our customers maintain their PCI certification, and is always able to help with custom configurations to suit an organisation’s requirements.

As PCI is a common requirement, we can share some details of how we are able to help.

Does PCI affect me?

If your website processes credit cards, then PCI almost certainly affects you. The definition of what other attached systems are in scope may mean that other systems associated with your payment processing systems may also be affected. Your PCI auditor will be able to help determine this.

What changes do we need to make?

The changes relate to the version of TLS that your site supports. TLS and SSL are the family of encryption protocols that enable HTTPS websites. There has been a long history of versions, from SSLv2 which was released with Netscape Navigator in 1994, through SSLv3, TLS 1.0, 1.1 and 1.2. TLS 1.3 is currently being developed and is going through the standardisation process.

Of course, 1994 is a long time ago in security history, and the various versions of SSL and TLS have proven to be less secure over time. A fun timeline of the history of these protocols and when they were deprecated is on the Feisty Duck website, in their SSL/TLS and PKI History.

Nowadays, as-at 2 March 2018, SSLv2 and SSLv3 are considered insecure. TLS 1.0 and 1.1 are still acceptable for some uses, but all websites should encourage browsers to use TLS 1.2 if possible.

The PCI Council requirement is that SSLv2, SSLv3 and TLS 1.0 should be disabled on your site. They strongly recommend that you also disable TLS 1.1 as well:

https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls

RedShield is able to make this change on your behalf, but there are a few things you should consider and be aware of.

What will break if we disable TLS 1.0 and 1.1?

Modern browsers support TLS 1.2, and so most regular web visitors will be able to visit your website without trouble.

However old web browsers on Windows XP or more ancient platforms, old Android phones, and other devices may not support TLS 1.2, and require TLS 1.0 to be enabled. Working out the compatibility requires looking at the browser, operating system and configuration settings which is outside the scope of this article, but has been done by others (e.g. Trend Micro, Salesforce).

Most browsers that support 1.1 also support 1.2, so disabling TLS 1.1 is typically less disruptive than disabling 1.0.

So the first thing to consider is how important older browsers and your customers that use them, are to your business. Some companies have sent strong signals to customers that they don’t want to interact with them if they are using out of date security (the “it’s for your own good” argument), while others aim to be as welcoming as possible to all customers.

The second consideration is non-browser users of your website. Many RedShield customers run API’s or integrate their websites with code running on different platforms. This third-party code may be written using outdated libraries, operating systems or technology stacks, and not support TLS 1.2.

If your websites support API consumers, you’ll typically take a more conservative approach to disabling TLS 1.0 and 1.1, and plan a communication campaign with your customers.

The Decision: Do we disable TLS 1.0 and TLS 1.1?

RedShield will not make this decision for you, and will allow you to keep using TLS 1.0 and 1.1 for the near future. Neither protocol is provably “broken”, and provide acceptable security in many scenarios.

Your company will need to make a decision based on the use of your website, whether it is in scope for PCI or other regulations, the browsers you wish to support, and whether there are non-browser users of the site such as API consumers.

When you have made your decision, contact RedShield support and we can help implement the required changes.

Things we can do to help

Statistics:

We don’t currently capture TLS version statistics for all customers, but can do so when requested or on an ad-hoc basis. If you would like to know what proportion of your visitors are connecting with each protocol version then you can request us to turn this stats gathering on.

TLS HTTP Headers:

We are also able to pass the TLS version to your origin web server as an additional HTTP header. This will allow you to capture and log these details, and correlate them with other business information. For example, you could compile a list of users with old TLS, or enable or disable site features based on the version supported. If you would like these HTTP headers enabled, please let us know.

Redirect older browsers to a landing page:

The problem with disabling TLS 1.0 is that browsers that don’t support TLS 1.2 will just fail to connect, with a browser error message. These users probably encounter these errors when they browse other sites on the internet, but it’s not a great user experience.

We have two options to allow older browsers to continue to connect to your website, but to give them strong guidance that they should upgrade their browser and operating system: a one-off redirect to an information page, or a permanent block and redirect to an information page.

The one-off redirect option allows us to redirect users to an information page on your website if they are using older TLS versions. We would redirect them on their first visit to your site, and then set a cookie so that they aren’t bothered subsequently.

For example, the first visit to https://example.org, we would redirect them to https://example.org/oldtls, and set a cookie. After reading the content on that page they could continue using your site as normal.

The permanent block and redirect option allows us to redirect visitors using an older TLS version to a different site, blocking access to your site until they upgrade their browser and operating system.

For example, any visit to https://example.org would redirect them to http://oldtls.example.org, and they will not be able to visit any pages on the main example.org site.

We recommend this option if you would like to prevent users from accessing your site, or you want to comply with PCI requirements without being too unfriendly to users.

We recommend that the landing page you redirect users to under this second option should be on a different domain name, and served over HTTP rather than HTTPS. This gives a strong signal that the originally intended site won’t work for their browser, and simplifies messaging and compliance. However, it does have the overhead of creating a secondary website.

RedShield can perform custom Shielding activities to enable either of these approaches, and to host a secondary site if requested. Please talk to your RedShield Solutions Architect or reach out to us at support@redshield.co if you’d like to discuss options.

In summary:

Removing support for TLS 1.0 is a PCI requirement that might make sense for your website. RedShield is able to assist in this transition, and has a few options to help ease the transition for your users.

As always, we are able to develop custom Shields to suit any web security scenario, just get in touch!