Are you prepared for the TLS 1.0/1.1 deprecation?

Are you prepared for the TLS 1.0/1.1 deprecation?
The Siliconreview
28 May, 2020

Endpoints are encrypted by TLS certifications – from tens of thousands to millions on the servers of major enterprises. Usually, these enterprises must manage them manually, which becomes a huge, time-consuming and cumbersome process. But it’s a crucial one: TLS certificates provide the assurance that consumers need to confirm the identity and trustworthiness of websites they’re seeking to transact with.

TLS - the successor to SSL - has been around for a long time. To be precise, it was normalized in 1999 to replace the archaic SSL 3.0, and has undergone three iterations ever since, with TLS 1.3 being the most recent. As is common practice, most internet systems have continued to support every version of TLS that has been released (1.0, 1.1, and 1.2 - with 1.2 being the most commonly used, as opposed to the newer 1.3). However, with the advent of the new decade, major internet browsers are officially pulling the rug out from under the earlier versions.

How will the deprecation affect users?

That’s right, by March 2020, TLS 1.0 and 1.1 was deprecated by Apple Safari, Mozilla Firefox, Microsoft EDGE/IE, and Google Chrome. In other words, if any of an organization’s outward-facing network services rely on these versions to function, these browsers will recognize them as insecure. And as far as internal usage goes, it’s a good practice to not use those versions to secure data in transit, either.

Pedagogic observations aside, what are the real-world effects of remaining on these soon-to-be-deprecated versions of TLS? For one, users risk continued exposure to the vulnerabilities of the older versions, Cipher Block Chaining (CBC) and downgrade attacks are shining examples of vulnerabilities that they were susceptible to. More importantly, systems on TLS 1.0 would not meet the requirements to comply with the PCI’s Data Security Standard (DSS) - which explicitly states that it only recognizes TLS 1.1 or higher, with TLS 1.2 being strongly recommended in order to sufficiently secure payments and transactions.

I’m convinced, but should I switch to TLS 1.2 or TLS 1.3?

The obvious answer here is TLS 1.3 - it’s newer, and brings way more significant security and functionality changes to the table than TLS 1.2 did when it was launched. Naturally, TLS 1.2 is more widely used - according to Mozilla, 93% of all TLS sessions in 2018 used TLS 1.2, while only 5.6% used its newer cousin. TLS 1.3 boasts of vastly superior performance and delivers features such as:

  • Zero/One Round-trip handshakes
  • Removal of SHA-1, AES-CBC protocols etc.
  • Nullified vulnerability to RC4 and Beast exploits
  • Perfect Forward Secrecy
  • Provision to encrypt SNI (Server Name Identification)

Preparing for an upgrade.

Making the leap to a newer TLS version is an inevitable occurrence, so the faster an organization prepares for it, the better. However, it isn’t as easy as simply flipping a switch - there are several things to consider before deciding to rehaul TLS-dependent systems.

#1: Ensure Endpoint Support

The first and most important aspect of planning a migration is ensuring that the endpoints support TLS 1.2 or higher - be it, for instance, securing data in transit for server to server, or server to browser, or even for internal communication for APIs and web services.

#2: Endpoint Configuration

One must also ensure that the endpoints are configured properly to ensure that they only support the protocol they are migrating to.

#3: SHA-2 Certificates

Finally, all the certificates on the organization’ machines must be replaced to support SHA-2. Moreover, if there are older web servers that don’t support the new protocol, miscellaneous software and hardware upgrades might be necessary.

Pre-migration challenges

Any organization is likely to have thousands to tens of thousands of endpoints communicating with each other via the network. Every one of these endpoints must be compatible with the new ciphers and libraries that a TLS migration would entail. In the event of a non-compatible endpoint being overlooked pre-migration (which could be an application, a device, or anything else), it would fail to work post-migration - it is imperative that tests for such weak links are completed and remediated prior to considering a step-up, while maintaining roll-back capabilities, just in case.

Seven steps for a successful migration

Once the organization is fully prepared for an imminent overhaul of its TLS systems, here’s the steps to ensure a successful migration.

  • Configure every single end system to disable all versions of SSL and older versions of TLS (every version prior the one you’re migrating to).
  • Replace vulnerable protocols that are being run on those endpoints - and also document suitable secure configurations to be implemented on the fly.
  • Create a map of every client-server communication to easily identify the system components and data flows that rely on the obsolete protocols.
  • Ensure server and endpoint compatibility with TLS 1.2/1.3 ciphers.
  • Post-migration, set up periodic validations to ensure that all your systems support only the new protocols.
  • Block the vulnerable ciphers (TLS 1.0, 1.1) on all endpoints.
  • Retain the capability to roll-back to the last known working configuration, in the event of migration side-effects that threaten business continuity.

Post-Migration: Ensuring that PKI works with the new TLS configurations

PKI (Public Key Infrastructure) and TLS overlap in several integral areas, and often go hand-in-hand. Once network systems are successfully configured to work with TLS 1.2 or 1.3, it’s important to check on the PKI and x.509 certificates that act as digital identities for every one of those systems, and prime them to work with the new protocols. Given that an organization have thousands of certificates and keys on hand, and certificate management is a perennially ongoing process, this activity cannot be jury-rigged.

Everything that needs to occur can be distilled into three steps:

Step 1: Scan the network and identify the vulnerable clients and servers that use the SHA-1 algorithm.

Step 2: Renew the certificates on those network entities - ensure that all the certificates on the network are SHA-2.

Step 3: Push the certificates to their respective endpoints and install or configure them accordingly.

About the Author: Murali Palanisamy is Chief Solutions Officer of AppViewX. He previously served as senior vice president at Bank of America, where he led an architecture and engineering team of ecommerce application delivery. He was previously vice president of architecture and product engineering at Merrill Lynch. He has designed and developed automation and integration solutions for servers, application delivery controllers, IP services, and networking.

Murali is an electronics and communication engineer from Bharathiyar University in India, and is based out of New York.