The recent disclosure 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.
This guide is designed for organizations seeking to build a high-performance, highly secure TLS infrastructure—one that leverages the full power of TLS 1.3 while maintaining strict cryptographic key controls.
What’s New in TLS 1.3
TLS 1.3 is a significant step forward, providing both performance and security upgrades.
Forward Secrecy by Default
Forward secrecy (PFS) ensures that even if a server’s long-term private key is compromised, past encrypted sessions remain confidential and cannot be decrypted retroactively.
TLS 1.3 enables PFS automatically. For earlier versions, you must explicitly configure ephemeral Diffie–Hellman cipher suites (ECDHE-ECDSA, ECDHE-RSA, DHE-RSA, DHE-DSA).
Understanding this difference is critical:
TLS Without Forward Secrecy
The client uses the same long-term server key for key exchange. If that key is ever compromised, past session data becomes exposed.
TLS With Forward Secrecy
The server generates a unique ephemeral key pair for each handshake.
-
The long-term key only authenticates the ephemeral key
-
The ephemeral key performs the key exchange
-
The compromise window is dramatically reduced
This distinction is essential when balancing security with performance optimization.
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.
How GaraTrust Strengthens Enterprise TLS Deployments
GaraTrust simplifies and secures TLS key management by providing:
✓ HSM-backed storage of all private keys
Server keys, CA keys, TLS inspection keys, and more.
✓ Native integrations across all major platforms
Microsoft • Apple • Linux • OpenSSL • GPG • RPM • Debian
✓ Centralized control over who can use each key
With MFA, device authentication, JIT access, location controls, and approval workflows.
✓ Proxy-based enforcement
Keys never leave the HSM. All cryptographic operations flow through a controlled, auditable layer.
✓ Unified visibility and governance
Audit every key operation, revoke access instantly, and manage all TLS, code signing, S/MIME, and SSH keys from one interface.
Whether you’re modernizing TLS for performance or deploying zero trust at scale, GaraTrust provides the cryptographic foundation needed for secure, enterprise-wide adoption.
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 GaraTrust for securely managing keys, proper certificate lifecycle management tools to avoid outages, etc.— others will require custom solutions unique to their specific environment.
GaraTrust, 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— GaraTrust makes it easy to secure all of your private keys in hardware security modules at all times. At the same time, GaraTrust 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. GaraTrust 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 GaraTrust or setting up a demo, get in touch with the Garantir team.
