With last week’s announcement of the Raccoon Attack that impacts TLS 1.2 and below, the announcement of TLS 1.3 just two years ago, and the ever growing popularity of TLS proxies being used in zero trust architectures and SD-WAN implementations, now is the perfect time to brush up on TLS.
For those who aren’t too familiar with TLS, there are plenty of general blogs and articles out there that will help you get a basic understanding of what it is and how it works. This one is a little different. It’s designed for enterprises wishing to deploy a scalable TLS infrastructure that securely takes advantage of the protocol’s performance enhancement capabilities.
New Features in TLS 1.3
TLS 1.3 is a significant step forward, providing both performance and security upgrades.
Forward Secrecy
Forward secrecy, also known as perfect forward secrecy (PFS), assures that session keys will not be compromised even in the event that the long-term keys used in the TLS handshake are compromised. Practically speaking, this means that even if the server’s long-term private key— that is, the private key whose public key is in the server’s SSL/TLS certificate— is compromised, data sent via previous TLS sessions established with that private key will remain secure and cannot be retroactively decrypted.
Forward secrecy is obviously highly desirable and should be used wherever possible. TLS 1.3 has it enabled by default but for previous TLS versions you will have to choose the appropriate cipher suite to enable it (ECDHE-ECDSA, ECDHE-RSA, DHE-RSA, DHE-DSA, where the E stands for “ephemeral”).
In order to optimize your use of forward secrecy, it is important to understand the basics of how TLS works. First, let’s look at the relevant portion of a TLS handshake without forward secrecy:
The key takeaway here is that the client uses the public key from the server’s TLS certificate to perform the key exchange. Since this public key is static (at least until the server changes the certificate and uses a new public key), the same public key will be used on all TLS handshakes, regardless of client.
Now, let’s take a look at a high-level diagram of a TLS handshake with forward secrecy:
The main point to understand here is that the server generates a unique key pair for each TLS handshake, which is known as an ephemeral key pair. The client uses the public key from the server’s certificate to validate the public portion of the ephemeral key pair, and then performs the key exchange using the ephemeral key. This fact will come in handy when we look to implement performance enhancements without sacrificing security.
TLS Key Management
Like many other security protocols, a TLS implementation is only as good as its key management. If you’ve been keeping up with Garantir’s blog, you’ll know that we are strong advocates of using hardware security modules (HSMs), and this post is no exception. However, while it is easy to simply say “use an HSM” (and we do say that), it is important to take a deeper look at the keys used in TLS to better understand which keys need what level of protection.
An Overview of TLS Keys
Server Static Key Pair – This is the long-term key pair whose public key is in the server’s TLS certificate.
Server Ephemeral Key Pair – This is the short-term key pair whose public key is used for key exchange when forward secrecy is enabled.
Client Key Pair – This is usually an ephemeral key pair generated by the client on a per-session basis. However, this can also include a static key pair when mutual TLS is being utilized. Since this post is mostly about server-side deployment, we are going to ignore these keys.
Session Keys – The symmetric keys, derived from the master secret, are used to encrypt (and MAC) the data sent after the TLS session has been established. The server and client use different symmetric keys when encrypting data to each other, but both sides know all the symmetric keys.
Certificate Authority Key Pair – This is the long-term key pair used to sign certificates for servers (and, sometimes, for clients). In most cases, this will be a publicly-trusted certificate authority but in some cases you may be your own certificate authority. Furthermore, in cases where TLS inspection is desired, you may be dynamically issuing server certificates on the fly.
Keeping TLS Keys Secure
From a purely security perspective, it is desirable to say that all of these keys must be in the HSM, but this isn’t always practical or possible. The keys that should definitely be generated, stored, and used (in a non-exportable manner) in an HSM are the Server Static Key Pair and the Certificate Authority Key Pair (note that the CA may be a third-party, in the case that you’re using publicly-trusted CAs).
The need to use the HSM for the Server Ephemeral Key Pair is dependent on the specifics of your environment. For example, if the ephemeral key pair is generated only after the TLS handshake is initiated, and then wiped from memory as soon as it is no longer needed, the requirement for HSM storage of these keys is not as strong (but still should be used whenever possible, especially when processing highly sensitive data).
However, if the ephemeral key pair will live on for longer than the short timeframe than it is in use, as is the case when pre-generating ephemeral key pairs for performance reasons (more on this below), the use of the HSM is strongly recommended and may even be a hard requirement. In this case, the system must be carefully designed so as to not exceed the key capacity of the HSM you’re using.
Using your HSM to secure Session Keys is only necessary when processing very sensitive data over the TLS channel (e.g., government classified). Designing such a system requires careful planning, especially when the TLS server is in a high availability cluster and replication of the Session Keys across HSM sessions is necessary.
The HSM performs many important functions that become your responsibility when you choose not to use the HSM. Examples include, but are not limited to, secure key generation, protection of key bytes, and secure deletion. Without the strong random number generator, secure interfaces, and hardware protection provided by the HSM, these tasks can be tricky to accomplish, especially with third-party software. For this reason, if and when you can use an HSM to secure TLS keys, it is strongly recommended that you do.
Enhancing TLS Performance
The first performance enhancement technique you should consider is enabling TLS 1.3 on all your servers and clients. This will automatically give you 1-RTT handshakes, which will result in noticeably faster page loads. For those that want to go a step further, there is the 0-RTT handshake feature, but be warned, this feature is subject to replay attacks if not used correctly. 0-RTT should only be used for non-state-changing requests (e.g., GET requests).
Once that is accomplished, there are two other techniques you can implement for further performance gains: pre-generation of ephemeral key pairs and precomputation of keystreams.
Pre-Generate Ephemeral Key Pairs
Generating a new key pair is a slow process so instead of creating the ephemeral key pair once the TLS handshake process is initialized, consider pre-generating these ephemeral key pairs and picking from the available pool when needed. This allows the TLS handshake to complete faster at the cost of higher memory consumption and slightly lower security as the ephemeral key pairs have an increased lifetime. This security impact can be reduced by generating and storing these keys in an HSM.
Pre-Compute Keystreams
If you are using one of the standard ciphers for TLS 1.3 (e.g., AES-GCM) you can precompute the keystream to save on time encrypting data. Similar to above, this performance gain comes at the cost of higher memory consumption.
Practical Considerations for Large Enterprises
Many large enterprises have restrictions, often out of their control, that they must consider. Examples include:
- Legacy systems that are challenging to upgrade
- Requirement to inspect TLS traffic
- Servers and cryptographic keys managed by different teams
- Low tolerance for outages or downtime
For these enterprises, robust processes and tools must be in place in order to successfully upgrade their TLS infrastructure. While some of these problems have reasonably well-defined solutions— TLS proxies for legacy systems and inspection, a centrally-managed key management platform like GaraSign for securely managing keys, proper certificate lifecycle management tools to avoid outages, etc.— others will require custom solutions unique to their specific environment.
GaraSign, Garantir’s flagship product, is a solution that fits directly into any enterprise environment. With native client integrations to every major tool and platform— Microsoft, Apple, Linux, GPG, OpenSSL, RPM, and more— GaraSign makes it easy to secure all of your private keys in hardware security modules at all times. At the same time, GaraSign enables you to manage all of those keys from a single interface. End-users are always restricted to proxied key access, so granting, auditing, and revoking access to keys is simple. GaraSign works with TLS keys but it’s also compatible with a number of other private-public key pair use cases, including code signing, S/MIME, SSH, and more.
If you’re interested in learning more about GaraSign or setting up a demo, get in touch with the Garantir team.
