TLS at the edge and server-side security

We’re huge fans of Transport Layer Security (TLS) at Fastly. Here’s a behind-the-scenes look at how we do encryption at the edge, which can also serve as overall best practices for handling server-side TLS.

Getting a certificate

If you opt to get your own certificate, keep in mind that some certificate authorities (CAs) try to streamline the process of issuing a certificate for a client by generating the public/private key pair in addition to a certificate corresponding to the public key.

This removes two steps from an administrator’s to-do list (generating a key pair and generating a certificate signing request for the key pair), but it does so at great expense to security. If your certificate authority creates your private key, you’re trusting them to generate it properly (using a strong, cryptographically secure source of randomness), transmit it to you securely, and to irrecoverably delete their copy of the private key when the process is complete.

That’s three separate assumptions that could haunt you if they go wrong, compromising the security of your entire TLS deployment. If you decide to get your own certificate, it’s important to generate your own key pairs — this will give you more control and greater peace of mind. Since your CA doesn’t need your private key, it’s safest to never give it to them. Make sure the private key is sufficiently protected on the server — tighten the file permissions to only allow access by the root user and the web server.

If you’re a Fastly customer, we can generate certificates and key pairs on your behalf, bypassing security worries and reducing overall management overhead. For example, when the Heartbleed bug was identified, we were able to regenerate all of our certificates’ key pairs quickly. If you were managing your own cert, you would have been responsible for quickly re-keying on your own.

Double-check CN fields/SANs

After you have a TLS certificate, make sure the common name (CN) and subject alternate name (SAN) fields in the certificate match the DNS names your server supports. Your cert needs to have all the names your server responds to. A frequent mistake is forgetting to include “www” in additional to yourdomain.com. For example, if we were setting this up for Fastly, we’d want to include www.fastly.com as well as fastly.com.

If you add any new domain names or subdomains to a server configured for TLS, then you must also update the configured certificate to include these new names — otherwise your users will encounter a warning message indicating the server’s certificate could not be trusted.

Appropriate key sizes/algorithms

The size of your private key determines the strength of the cryptography used in TLS. The larger the key size, the greater the theoretical effort required to break the encryption.

When choosing a key size, it’s important to remember that you’re not only planning for today, but also for the future. The National Institutes of Standards and Technology offers guidance on appropriate key sizes for a selection of cryptographic algorithms, which depend on how many years you want the key to be safely usable.

• For RSA keys, you should use a key size ≥ 2048 bits.

• You should not use Digital Signature Algorithm (DSA) keys at all (an Internet Explorer limitation means only DSA key sizes at ≤ 1024 bits are supported — this does not provide the required amount of security for 2015 and beyond).

• For Elliptic Curve Digital Signature Algorithm (ECDSA) keys, you should use a key size ≥ 256bit. ECDSA keys are an attractive option due to their strength to key size ratio — it takes fewer ECDSA key bits to achieve the same security as a larger RSA key. Deployment of ECDSA keys and certificates is somewhat problematic today due to the relatively new support for ECDSA in web browsers. This will get better with time, making ECDSA a more popular option for system administrators.

As mentioned above, if you let Fastly generate your certificates, we’ll pick the appropriate algorithm and key size for your individual needs.

TLS configuration

There are two main points of TLS configuration you need to consider:

Ciphersuite selection and TLS version

TLS has a long history with many lessons learned along the way. While progress on new and improved versions of TLS has been steady, adoption hasn’t always kept up. Although backwards compatibility is seen as a generally positive goal in many systems, in security systems you are only as a secure as the least secure option available. Security is often compared to a physical chain in this sense — it is only as strong as the weakest link. If your TLS deployment includes old features for backwards compatibility, those are the features an attacker will target, not the strongest ones.

It’s important to turn off support for old TLS/SSL versions and to avoid cipher choices that are no longer considered secure by modern cryptographic standards. It’s particularly important that you don’t offer any intentionally crippled “export level” ciphers, such as the “null” cipher (which does no encryption at all) or EXPORT-RSA (which uses trivially breakable key sizes), broken or outdated ciphers such as RC4, or any MD5-based configurations. Mozilla has a tool to generate ciphersuite configurations based on your OpenSSL version, web server version, and backwards compatibility requirements.

Ephemeral key exchange

A great way to improve the security of your TLS configuration is to offer ciphersuite choices that employ an ephemeral key exchange method. The ephemeral key exchange ensures that session keys established during the TLS handshake between client and server are, in fact, ephemeral. Once the session ends, the session key is essentially gone, and can only be recreated by the two original parties (client and server) working together, preventing an outside party from decrypting the traffic after the fact.

Without an ephemeral key exchange, an adversary is able to capture TLS-encrypted traffic that can be recorded and archived for later decryption. Days, months, or years later, if that adversary can obtain the server’s private key, they will be able to decrypt that recorded traffic. An oft-repeated cryptography adage is that attacks only get better, never worse. Your TLS configuration should try to make captured traffic useless for post-hoc decryption as much as possible, a property of cryptographic systems often referred to as “perfect forward secrecy.” By favoring ciphersuites that use an ephemeral key exchange method, you ensure that if someone has archived your TLS traffic they will not be able to decrypt it after the fact, even if they obtain the private key used by the server in the process of establishing the ephemeral session key.

Intermediate certificates

Think of the chain of certificates as an upside-down tree; the root CA is the root of the tree, the intermediate CAs are the branches, and the website’s certificate is the leaf. It’s called a “root” because nothing endorses its identity; it endorses itself. The root CA is trusted on the basis of being included as part of your operating system or browser rather than being vetted by another entity. The leaf is the last certificate in the chain, and the one concerning the identity of the website. The other certificates (from the leaf upwards) are concerned with validating the identity claimed by the leaf certificate. Keep in mind that you can’t simply serve the CA-signed leaf certificate that you’re using for your website. You must also serve any of the certificates required to build a chain of trust from the leaf certificate’s issuer to a root CA on the client’s machine. This is part of the TLS negotiation process; when a client connects to your website, they accept the identity your server’s certificate claims to represent by establishing a chain of trust, which involves checking how and to whom you verified your site’s identity. If you miss an intermediate cert, then clients won’t be able to trust your server’s claimed identity and a TLS error will be shown in the browser.

Redirecting HTTP to HTTPS

Now that you’re offering a more secure way of accessing your site, you have to make decisions on how you’ll redirect visitors from your old site to the new, more secure version. The best practice is to redirect with a 301 response to the HTTPS version of your website. You should do this immediately, and not as the target of a form post (e.g., waiting until the user tries to log in). You can make it so a redirect is not required each time a user accesses your site by serving an HTTP Strict Transport Security (HSTS) header informing the browser that it can always expect to visit your website over TLS.

This is how Fastly ensures the best encryption at the edge, but these best practices also serve as an excellent guideline for TLS at your origin. We recommend TLS encryption for both your own infrastructure and for any caching you’re doing — this ensures maximum security while maintaining performance at the edge.

Stay tuned: our next TLS-related post will cover best practices from the client side.