TLS Key Size: Why Bigger isn't Always Better | Fastly
Configuring 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 4096-bit RSA key over the typical 2048-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.
In all versions of the TLS protocol, the certificate plays a very specific role: it is used when validating the hostname 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 prior to the compromise.
By default, the Fastly CDN 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.
A modern CDN gives you huge improvements in caching, SEO, performance, conversions, & more.
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 2048-bit RSA key provides 112-bit of security. Given that TLS certificates are valid for a maximum of one year, 2048-bit RSA key length fulfills the NIST recommendation until late in this decade. In addition, PCI DSS requires the use of “strong cryptography” which is currently defined as RSA 2048-bit or ECC 224-bit (or higher) encryption keys.
Even if a larger 4096-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 2048-bit verification operations running four times faster than 4096-bit RSA key verification. When that impact is combined with the additional data that must be transmitted to the client when using a 4096-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.
An even better solution to this problem is to switch from RSA to ECDSA keys. ECDSA uses a different mathematical construct than RSA and results in much smaller key sizes providing strong levels of protection. A 256-bit ECDSA key provides 128-bits of security, equivalent to a 3072-bit RSA key. Now that Fastly supports ECDSA certificates, there is no longer any need to trade off performance for the increased security offered by a certificate that uses 4096-bit RSA keys. If you are concerned about switching to a relatively new cryptographic algorithm (ECDSA was invented in the 1990s), then you might want to look around. A recent visit to Google.com returned an ECDSA certificate.
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 tradeoffs between security and compatibility with older clients that may not support TLS 1.3. Mozilla publishes recommended configurations that take these tradeoffs into consideration. For TLS server certificates, 2048-bit RSA keys or 256-bit ECDSA 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.
Four Things Every Security Director Should Know About GraphQL
An increasing number of developer teams are using GraphQL due to its efficiency, speed, and specificity over other query languages such as REST and SOAP. Educate yourself on GraphQL and how to make sure you're getting ahead of any security considerations for your applications and APIs using it. Download the white paper
