1.2.8 Supporting Legacy Platforms
Sometimes you’ll find yourself needing to support legacy clients that don’t have the latest and greatest security features. In this case, you will need to reach out for, and enable, certain components that are not ideal but are still acceptable for use in exceptional situations. It could be that the risk of the exploitation is low or that the service is not that valuable, or perhaps you have mitigation measures in place. If you are in this situation, this section is for you; I will outline here some of those imperfect but palatable legacy features.
The good news is that it’s generally possible to deploy strong and weak elements at the same time, relying on the TLS negotiation features and server configuration to ensure that individual connections use the best commonly supported features. This means that those weak elements in your configuration will be used only as a last resort.
If you have to resort to using some of these weak encryption components in production, consider splitting your systems into those that are well-configured and those that are intended to serve your legacy clients. Structuring your deployments like that will help you minimize the risk.
- RSA private keys
-
The ECDSA algorithm is gaining in popularity on account of its speed, but you will often find that it’s not supported by some old clients. In this case, fall back to the RSA algorithm. If you care about performance, deploy with two certificates, using both ECDSA and RSA at the same time.
- TLS 1.1, TLS 1.0, SSL 3, and SSL 2
-
Legacy clients won’t support TLS 1.2, so you may need to enable TLS 1.0 for them. This is not terrible and you may find that my recommended suite configuration works for you. If you’re considering SSL 3, then you should carefully study the weaknesses of this protocol and determine if its use is acceptable in your situation. SSL 2 cannot be used securely—and it’s worse than no encryption because this protocol version can be used to exploit secure servers (via DROWN). Nobody cares about TLS 1.1.
- Weak Diffie-Hellman key exchange
-
There are some old clients (e.g., Java before version 8) that can’t use the DH key exchange at 2,048 bits, which is the recommended strength today. You may consider dropping the strength to 1,024 bits to accommodate these clients. If you do, you must generate a unique set of DH parameters on each server. You must not use any of the predefined well-known groups because they can be exploited via a precomputation attack. Anything below 1,024 bits is very easy to exploit.
You need to be aware that if you reduce the DH strength, it will affect both modern and legacy clients. This is one aspect of TLS configuration that cannot be negotiated on a per connection basis. The best approach is to have separate systems for modern and legacy customers. If you can’t do that, preferring the ECDHE key exchange (as in my recommended configuration) will ensure that modern clients all use ECDHE and never attempt DHE.
- Weak cipher suites
-
Very old clients were never capable of great encryption—for example, often not supporting DHE and ECDHE key exchange or the AES encryption algorithm. This is effectively the situation with Windows XP and some early Android platforms. Therefore, to communicate with those platforms you’ll have to support the plain old RSA key exchange that doesn’t provide forward security. And for Windows XP, you’ll need to support 3DES (slow and on the way down, but not entirely out, strictly speaking). Here are some last-resort suites to place at the end of your prioritized list of suites if there is no other way:
TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA