Introduction
As you all know by now, it really is time to say goodbye to TLS 1.0/1.1. You might be ready to only offer and support TLS 1.2. Perhaps you can even add TLS 1.3 as well. Being able and willing to block TLS 1.0/1.1 is a good thing completely. Well done.
Today, only about 0.5% of web browser activity is over TLS 1.1/1.0. For my own webservices, I know it is less than 1%. It is actually just above 60% TLS1.3 and 39% TLS1.2. As a result, enforcing TLS 1.2 is probably not your biggest concern or challenge when it comes to browser versions in use today.
The problems might lie in 3rd party software and services that cannot use TLS 1.2 yet. Maybe the libraries they use are from the stone age. Maybe someone decided that the TLS version to use was TLS 1.1 and they forced it in the code. Code you perhaps don’t have access to and/or life cycle management is non-existent. This means the application or service won’t pick up the default of the operating system that might be TLS 1.2 or 1.3. Sometimes there are workarounds to this, but sometimes there are none. Allowing clients to connect to older TLS versions on your public end points and translating these to a newer TLS version can help you deal with this.
For some of the same reasons, you might not be able to block TLS 1.0/1.1 internally. But you do not want the external parties to be forced to connect to TLS1.0/1.1. Instead, you only want to offer TLS1.2 and TLS 1.3 offered to clients, so that modern clients that no longer support TLS 1.0/1.1 (20 h of March 2020 is D-Day) won’t have issues connecting to your public end points while internally you connect to your services via TLS 1.0/1.1.
With a load balancer, you can switch between TLS versions via decrypting and re-encrypting. So, the above scenarios can be dealt with. There is, however, an extra technical hurdle to deal with if Server Name Indication (SNI) is in use to offer multiple sites on the same IP address and port with different certificates. This is not uncommon.
In this article, we will look at how we can decrypt / re-encrypt multiple certificates on the same IP address and port while requiring SNI with a Kemp LoadMaster Application Delivery Controller (ADC aka a load balancer, reverse proxy …). This will help us deal with the challenges we face when SNI is needed to support multiple certificates on the same IP address and port while performing our TLS version translations. You could actually terminate TLS on the ADC, which would make it “SSL Offloading”. Most environments I work in require “end to end” encryption, both over the internet as well as internally. There is no “secure zone”, we assume someone is listing on the network. You can do this in the cloud or on-premises with many tools and products. You probably already have used it without realizing it. If you use cloud flare, for example, you will leverage TLS 1.3 even if the actual backend service does not support it. But here, in the scenario, we use a Virtual LoadMaster.
TLS translations
This is an easy issue to solve. The reason why you need to support TLS 1.0/1.1 doesn’t really matter. The issue is that it does hamper your efforts to turn of fTLS 1.0/1.1 internally. It is quite easy to disable all the old SSL versions, TLS 1.0/1.1, the weakest ciphers, and enable perfect forward secrecy with a script. For Windows servers, these scripts are very good and popular ones. But how can noncompatible clients still connect if needed?
With a load balancer / reverse proxy / Application Delivery Controller etc. you can solve this issue. You allow clients to connect to the VIP via TLS 1.0/1.1, but the load balancer then talks TLS 1.2 with your real servers. Hence, you can block TLS 1.0/1.1 on all your internal servers sitting behind a VIP on a load balancer. Internally, you are rock solid. In a test tool like Qualys SSL Labs will show up as still supporting TLS 1.0/1.1. That is the price you pay for still allowing older TLS versions.
The reverse might also be true. The clients should only connect to TLS 1.2 or TLS 1.3, but you can’t get rid of some internal services requiring TLS 1.0/1.1. Well, with a load balancer you can play that game as well. The benefit being here is that a test site like Qualys SSL Labs will grade you with an A and won’t show support for TLS 1.0/1.1. Internally, you use TLS 1.0/1.1, as needed, until you can resolve that legacy issue. The cool thing is that leveraging an ADC will even give you the ability to support TLS 1.3 for client connections even if your services cannot support it yet.
The real challenge
The above sounds easy enough right? Well, yes and no. if you have real servers with a single site and one IP address or multiple sites with each a different IP address you are golden. You can do the above with ease. The real challenge is when you have multiple SSL sites sharing the same IP address and port that need to be bound to multiple SSL certificates or a SAN certificate. This requires “Server Name Indication” (SNI). That is fine on the real servers. But if you pass by a Kemp Loadmaster and have only one VIP (because the sites share a single IP address) leveraging SNI can become a bit more complicated.
With a Kemp LoadMaster, you will need to leverage sub virtual services (SubVSs) to handle this scenario. But we need to use SSL decryption and re-encryption in order to support the clients and servers with different TLS versions. Re-encryption is handled at the virtual service (VS) level, not at the SubVS level. Meaning you can only enter one SNI name for re-encryption with a shared VIP. So, in the case of two or more SSL sites sharing the same IP address, you would have only one that works. So how do we work around this?
How to re-encrypt multiple SNIs on the same IP with Kemp LoadMaster
You can get this to work through a combination of a VIP on a virtual service (VS) with sub-virtual services (SubSV) together with content rules that point to a dedicated intermediate VS per website/domain/certificate, which points to the actual real servers.
We also have to decrypt and re-encrypt the traffic so we can translate between TLS versions. The parent VS can require SNI but doesn’t have to. But here I want it to be required. Next to that, we also leverage content rules here to match traffic and host names.
We need this in order to send the correct traffic onward via the matching SubVS to the downstream VSs. The key here is not to use an SNI host name for re-encryption on the parent VS.
At the downstream intermediate VSs, we don’t require SNI; this is because we did not specify a re-encryption SNI hots name. If we required an SNI name here, it would break the solution. We do decrypt and then re-encrypt while specifying the SNI name for re-encryption. This means our real servers get the correct FQDN for SNI checks and are happy. If you do not specify a re-encryption SNI hots name here, the solution would break on the real servers requiring SNI. It is at the intermediate VSs that you must do the health checks for the real servers.
Also, note that we do not need to have health checks on the SubVSs themselves. You must check the health on the downstream VSs pointing to the real servers. When you do the same health checking on the SubVSs as well, you must test your LoadMaster High Availability failovers. The results can be less good when you do health checks on both places. Your mileage may vary.
The above picture shows this schematically. All this might sound a bit tedious to setup. But once you wrap your head around it, it makes sense. I will go through this step by step with you in the second part of this article.
