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 will be deprecated by Apple Safari, Mozilla Firefox, Microsoft EDGE/IE, and Google Chrome. In other words, if any of your 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 your 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. However, it 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 one needs to consider before deciding to rehaul their 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 your 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.
Any organization is likely to have thousands to tens of thousands of endpoints communicating with each other via the network. As we’ve mentioned before, every single 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.
Our recommendations for a successful migration.
Once you’re fully prepared for an imminent overhaul of your TLS systems, we recommend you keep this little cheat-sheet handy to ensure you dot all the I’s and leave no stone unturned in executing 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: How can I ensure that my PKI works with my new TLS configurations?
PKI (Public Key Infrastructure) and TLS overlap in several integral areas, and often go hand-in-hand. Once you’ve successfully configured your network systems to work with TLS 1.2 or 1.3, you’re going to have 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 you might have thousands of certificates and keys on hand, and certificate management is a perennially ongoing process, this activity cannot be jury-rigged.
To help you out, we’ve distilled everything you need to do into three steps:
Step 1: Scan your 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 your network are SHA-2.
Step 3: Push the certificates to their respective endpoints and install or configure them accordingly.
How can AppViewX help?
Building on the aforementioned three steps – if you work with certificates and PKI, you already know that flipping through an entire inventory of certificates, weeding out non-compliant ones, and working with a CA(s) to get them updated or renewed is no walk in the park. Attempting to do it manually can take hours, days, or even months, given that you’d want zero network downtime or service disruptions while this happens.
AppViewX, in a nutshell, is a GUI-based certificate lifecycle management and automation tool. Which means it can assist your TLS migration tremendously by accelerating the PKI processes involved and also streamlining them to ensure that it is not plagued by human error.
In this particular case, AppViewX helps you automate everything. Literally. The platform will, systematically, help you define parameters and scan your entire network to locate the vulnerable certificates, set up an automation workflow to renew or remediate those certificates in bulk, and also automate the installation of the updated certificates on specific endpoints. Finally, you can also set up post-migration validation scans to check if everything works as expected on the PKI front. And that’s just the tip of the iceberg.
To learn more about us, or set up a session with us to learn how we can personally assist you with your requirements – you can do that here.