There have been some stories recently about the death/deprecation of TLS 1.0 and 1.1. They follow a similar format to those of a few years ago about SSLv3. The obvious question is, should you panic? The answer is, as always, it depends!
Web Apps
For commercial web apps you are hopefully doing the right thing and using a layered approach to your architecture. User traffic hits a load balancer that does the SSL termination, then maybe re-encrypts to send traffic to the web servers and/or app servers below it. It’s great if you can make all the layers handle TLS 1.2, but the only one that absolutely must is the load balancer. You can hide a multitude of sins behind it. Provided your load balancer isn’t ancient, your typical web traffic won’t be a problem. If you still allow direct traffic to web and app servers you might be in for a rough ride. The quickest and easiest way to progress is to slap a load balancer or reverse proxy in front of everything.
Server Call-Outs (Back-End)
Where it can get tricky is when the back end servers make call-outs to other systems. Back when SSLv3 was getting turned off, because of the POODLE vulnerability, a bunch of people took a hit because Oracle 11.2.0.2 couldn’t use TLS1.0 when making call-outs from the database using UTL_HTTP. Support for that appeared in 11.2.0.3, so the fix was to patch the database. Oracle 11.2 (when patched accordingly), 12.1 and 12.2 can all cope with TLS 1.2. You could have similar problems when using “curl” or “wget” on old/unpatched Linux installations. Obviously the same is true for old software and frameworks.
So what’s the solution from the back end? Depending on the ages of the software you are using, and what you are actually trying to do, it’s likely to be one of the following.
- Patch : You know you are meant to, but you don’t. This is one of those situations where you will wish you had. It always makes sense to keep up to date with patches. Often it means these sort of changes pass you by without you ever having to consider them.
- Upgrade : If you are using a version of software that can’t be patched to enable TLS 1.2 for callouts, you probably need to upgrade to a version that can.
- Proxy : The same way you can use a reverse proxy, or load balancer, to handle calls coming into your system, you can stick a proxy in front of outbound locations, allowing your old systems to call out with insecure protocols. The proxy then contacts the destination using a secure protocol. It’s kind-of messy, but we all have skeletons in our closet. If you have applications that simply can’t be updated, you might have to do this.
- Stop : Stop doing what you are doing, the way you are doing it. I guess that’s not an option right? 🙂
The first step in fixing a problem is to admit you have one. You need to identify your incoming and outgoing calls to understand what the impact of these and future deprecations will have. I’m no expert at this, but it seems like architecture 101 to me. 🙂
Deprecation Doesn’t Mean Desupport
True, but it’s how the world reacts that counts. If Chrome stops allowing anything less than TLS 1.2, all previous protocols become dead instantly. If a web service provider you make call-outs to locks down their service to TLS 1.2, deprecation suddenly means death.
You know it’s coming. You’ve been warned… 🙂
Cheers
Tim…
