The assumption that TLSv1.0 is hanging on only to service Internet Explorer Windows XP users (and therefore that disabling the protocol is trivial) is widely held but is most certainly false. Depending on the industry and target demographics of a website this can be a change that requires careful planning and metrics gathering. Disabling TLSv1.0 on a blog is easy (https://hjcotton.net/ – now TLSv1.2 only!) but on large e-commerce websites [particularly those targeted at business-to-business sales where technology upgrade cycles may occur at a slower pace] this protocol still directly facilitates sales. According to a blog post by Cloudflare on March 12, 2018, less than 4% of their total customer API traffic is using either TLSv1.0 or 1.1; but on an e-commerce site this traffic may still constitute significant revenue from customer orders.
Let me make it clear – TLSv1.0 needs to go. It’s vulnerable to BEAST and POODLE. PCI DSS requires TLSv1.0 to be disabled in favor of allowing only TLSv1.1 and 1.2 connections after June 30, 2018. This deadline has already been extended for two years and another extension seems unlikely this close to the deadline. As of the date on this post, nine out of ten top e-commerce sites tested below still supports TLSv1.0 – the only exception being Kohl’s.
curl -v -s --tlsv1.0 https://github.com/ -o /dev/null/ 2>&1 | grep -E "(< HTTP|error)"
To test sites for TLS version support you can use the curl command above (an “HTTP/1.1” response header indicates success in this case) or just punch in domains into SSLLabs’ Server Test.
Aside from two blog posts from GitHub and Cloudflare engineering teams in the last few weeks there hasn’t been much insight into the thought and processes large organizations are putting in to disable it. For anyone who’s looking at this June 30, 2018 deadline and charged with maintaining PCI compliance, these posts are invaluable.
How Did They Do It?
GitHub gave notice and a timeline on their blog back in February 2017 about the upcoming changes and a follow up post in February of this year. In addition to the notice they also had a single one hour brownout of TLSv1.0 connections as a temporary heads-up to draw attention from anyone using that protocol. Mind you, GitHub probably isn’t very concerned with maintaining support for old IE versions on Windows XP – their customer-base is pretty technically savvy and has likely long since upgraded to TLSv1.1+ capable browsers. However, their audience also integrates with their service far beyond just in-browser use (think automated build tools, integrated support in IDEs, etc.). One does not need to look particularly far on Twitter to see that dropping TLSv1.0 caused pain for at least some of its customer base.
If you’re having problems with GitHub tools not working, they’ve disabled TLS 1.0 and 1.1 within last hour or so. A whole bunch of stuff is broke. pic.twitter.com/iWO5Ch3qbv
— Kevin Beaumont (@GossiTheDog) February 22, 2018
Just a friendly reminder the Internet will be unavailable tomorrow as @GitHub will disable #TLS 1.0, 1.1 on https://t.co/0mWsM4pvDG — https://t.co/eoQ2BFjp6j @FiloSottile @ivanristic pic.twitter.com/9g7MQJarwF
— Serverless Oligarch (@evilSnobu) January 31, 2018
TLSv1.0 has been around for nearly 20 years and so it’s in almost everything! It’s in all manner of tools continuing to work silently in the background with much depending on them – and in an instant they’re going to stop working unless there’s a plan in place to [re]discover and upgrade/replace them.
Cloudflare is similar to GitHub in that their customer-base is technically-inclined (at least in regards to their API and Dashboard – end-user pass-through connections using their CDN service can continue to use TLSv1.0). Like GitHub Cloudflare has chosen to have a TLSv1.0 brownout period. Unlike GitHub, they are also detecting when API and browser connections to their customer dashboard are over the protocol and warning them of the upcoming change.
Finding Out How Much Dropping TLSv1.0 Will Affect You
According to CanIUse, TLSv1.1 and TLSv1.2 are either lacking or not enabled by default in every IE version 10 and under, in Firefox before version 27 and in Chrome before version 30. Note that the browser support for both 1.1 and 1.2 is almost identical and so some organizations are choosing to keep support for only 1.2. PCI DSS only requires dropping 1.0 so choosing to maintain 1.1 is a choice that can be made from traffic stats.
If you don’t have any log sources that can tell you what version of TLS clients are connecting with then your next best bet is to create a Custom Report in Google Analytics [or your analytics engine of choice] and filter on Internet Explorer 10 and below as they will probably be your pain points. Those browsers have support but it is not enabled by default.
Detecting TLSv1.1+ Support From Client Connections
The single-hour/day brownouts preventing TLSv1.0 connections that GitHub and Cloudflare used/are using are useful for discovering how your site is being used by A) internal tools your company or third parties may be using; i.e. automated scripts verifying that your website is online and B) by your customer base.
Besides programmatic use of your site either internally or by third parties for which ample notice and a brownout period can address, how can you let customers browsing your site know when their browser is connecting over TLSv1.0 and will cease to load your site when the switch is flipped permanently? There are two client-side options:
2. Create a site on a domain that does not support TLSv1.0 connections. Make an AJAX request to that site on page loads – if the connection fails then the lack of TLSv1.1+ support is likely the cause. As with option 1, show a TLSv1.0 warning to that user.
For bonus points with either option: log the user agent so you can build some stats on what browsers are being affected.
June 30, 2018
As of the date of this post, sites accepting credit card payments are but 90 days away from having to turn off TLSv1.0 to maintain PCI compliance and almost all large e-commerce companies have not made the switch preemptively. This TLS change will come down to the wire and it will be interesting to see exactly when and how these sites make the transition – and what fallout there might be.