Configuring Transport Layer Security (TLS) can involve some complex choices. This is certainly true when it comes to the size (number of bits) of the encryption keys used in server certificates.
It might seem prudent to choose a 4,096-bit Rivest–Shamir–Adleman (RSA) key over the typical 2,048-bit variety, especially when there is a need to protect information that is encrypted today for many years into the future. To explain why this decision is not so straightforward, we need to examine the function of the TLS certificate and the cryptographic operations used by TLS. Let’s dig in.
Strength of the session key is important
In all versions of the TLS protocol, the certificate plays a very specific role: it is used when validating the host name of the website and facilitates the creation of a session key that is used to protect the data in transit. This means that the strength of the session key is at least as important as the certificate’s key in protecting your data.
The strength of the session key is determined by the ‘cipher suite‘ that is agreed upon between the browser and the web server when establishing a TLS connection. The cipher suite also defines the method used to establish the session key.
Forward Secrecy (FS) is a property of modern key agreement mechanisms that ensures that the certificate’s private key can’t be used to recover the session keys. When a key agreement mechanism that provides FS is in use, a compromised key represented in the certificate cannot be used to recreate old session keys. Even if the encrypted TLS data is stored for a long time, cracking the certificate’s key will not allow the data to be compromised. In short, a compromise of your web server won’t allow the attacker to decrypt TLS traffic that was sent before the compromise.
By default, our content delivery network (CDN) at Fastly is configured to use FS when the browser supports it, and customers can ensure FS by requiring connections to use TLS 1.3, the latest version of the protocol, which only permits FS cipher suites, or by requesting a custom TLS configuration.
Read: Coming of age: a longitudinal study of TLS deployment
But what are the benefits of longer keys
The National Institute of Standards and Technology (NIST) periodically publishes recommendations on the use of cryptographic algorithms. They define the relative protection provided by different types of algorithms in “bits of security.” NIST recommends the use of keys with a minimum strength of 112 bits of security to protect data until 2030, and 128 bits of security thereafter. A 2,048-bit RSA key provides 112 bits of security.
Given that TLS certificates are valid for two years maximum (soon to be decreased to one), a 2,048-bit RSA key length fulfils the NIST recommendation until late in this decade. In addition, Payment Card Industry Data Security Standards require the use of “strong cryptography”, which is currently defined as RSA 2,048-bit or ECC 224-bit (or higher) encryption keys.
Even if a larger 4,096-bit RSA key isn’t necessary, what can it hurt? The answer is performance. Longer keys require more computation time on both the server and the client.
On Fastly servers, we recently measured 2,048-bit verification operations running four times faster than 4,096-bit RSA key verification. When that impact is combined with the additional data that must be transmitted to the client when using a 4,096-bit RSA server and intermediate certificate, the impact on performance is small, but material. By choosing to use a smaller key each year when renewing a certificate, you can enjoy better performance until it is time to begin using stronger keys.
Balance is key
In summary, the configuration of your web server is a critical factor in protecting data transmitted over TLS now and in the future. This involves some potential trade-offs between security and compatibility with older clients that may not support TLS 1.3. Mozilla publishes recommended configurations that take these trade-offs into consideration.
For TLS server certificates, 2,048-bit RSA keys currently provide the best combination of security and performance. Consider the role of the certificate and the impact on performance before choosing a larger key.
Adapted from original post which appeared on the the Fastly Blog.
Wayne Thayer works on security products and TLS as Senior Director of Engineering at Fastly.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.