It’s time for early Transport Layer Security (TLS) versions to die, die, die… which means that it’s time for all of us, if we haven’t already, to take our browsers, our projects and/or our organizations and upgrade, upgrade, upgrade.
Online merchants have until 30 June to support TLS 1.2 and HTTP/1.1: a kill date that was extended for these security sadsack protocols from the original June 2016 deadline, which the PCI Council decided that retailers weren’t going to make. We joe-schmoe netizens have until then to upgrade our browsers so we don’t get locked out of all the e-commerce sites that upgrade.
Dell EMC’s Kathleen Moriarty and Trinity College Dublin’s Stephen Farrell want the versions to be formally deprecated: The “die die die” comes from the URL of their Internet-Draft, which says it’s time to drag recalcitrant organizations and lagging projects into moving now, given a) how long the safer TLS 1.2 has been around and b) that the older versions are dangerous.
TLSv1.2 has been the recommended version for IETF [Internet Engineering Task Force] protocols since 2008, providing sufficient time to transition away from older versions. Products having to support older versions increase the attack surface unnecessarily and increase opportunities for misconfigurations. Supporting these older versions also requires additional effort for library and product maintenance.
TLS is the encryption on many of the internet protocols we use every day: for example, when we send authentication credentials and credit card information over the web, as well as for internet services such as email, FTP and VPN.
The ancient TLS 1.0 dates from 1999, while the crusty old TLS 1.1 hails from 2006. They’re pockmarked with security holes.
Remember Heartbleed, back in 2014? A simple syntax error made most versions of OpenSSL 1.0.1, a TLS implementation, completely useless for encryption.
Early versions of TLS and SSL also put organizations at risk of being breached by exploits including POODLE, BEAST, Shellshock and plenty more.
The Internet-Draft notes that support for TLS 1.0 has largely disappeared: numerous websites, standards, products and services including 3GPP 5G, CloudFlare, Amazon and GitHub have either completed their deprecation or will finish the job by July. Many of these have also dumped TLS 1.1 (or will, by July 2018.)
The PCI Security Standards Council notes that according to the National Institute of Standards and Technology (NIST), we can’t fix or patch SSL or early TLS. That makes it…
…critically important that organizations upgrade to a secure alternative as soon as possible, and disable any fallback to both SSL and early TLS.
The council says that online and e-commerce environments using SSL and early TLS are the most susceptible to the SSL exploits, but the 30 June 2018 PCI DSS migration date applies to all environments except for payment terminals (POIs) (and the SSL/TLS termination points to which they connect) that can be verified as not being susceptible to any known exploits for SSL and early TLS.
PayPal, for its part, put out a notice reminding merchants that they have to support TLS 1.2 and HTTP/1.1 by June 30: insecure connections will break after that.
As far as the rest of us non-merchants go, if you’re using a geriatric browser, you may find yourself locked out of PCI-compliant – in other words, e-commerce – websites after the deadline. Salesforce has this table of browser versions and support status, if you want to look up your browser… or you can just be greeted by no-shopping-for-YOU on 1 July – your choice!
Web Guy
All very well for browsers to expect every site to comply, but there are hundreds and thousands of bits of network kit which don’t have any ‘https’ option and some browsers seem unforgiving and uncaring if a user still REALLY WANTS ‘http’ access. Overkill for sites not accepting user input and just for display purposes, and it is sad to see everyone bowing to the god of Google and when it says “jump” they just say “how high?” not “why should we?”.