TLS Quick Reference Guide

I've written a lot about SSL and TLS and how to best configure your server to provide performance and security. This quick reference guide will go over all of they key points and link to more detailed information for further reading.

 

Protocol

 

SSLv2

SSLv2 has been broken for a long time and its use is no longer acceptable.

 

SSLv3

In Oct 2014, SSLv3 suffered the same fate. The POODLE vulnerability in the SSLv3 protocol resulted in a widespread removal of support for the protocol. Firefox and Chrome quickly announced they would be removing support for the ancient protocol in the browser and large firms like Twitter and CloudFlare announced that support would be removed from the server side. The protocol is proven to be breakable and if data is really in need of a secure transport layer, SSLv3 support should be removed.

 

TLSv1+

Hosts should offer their visitors a choice between TLSv1, TLSv1.1 and TLSv1.2 as a compromise between offering the most secure protocol and widespread support. There are currently no known vulnerabilities with these protocols and their use is considered safe.

 

SPDY

SPDY, or SPeeDY, is a web protocol developed by Google and aimed at providing better performance. It's available only over a secure trasport layer, offers header compression, multiplexed streams, request prioritisation and support in major browsers out of the box. Implementing SPDY support is a no brainer.

 

OCSP Stapling

The Online Certificate Status Protocol is used to check the revocation status of X.509 certificates, or TLS certificates to you and I. Rather than a client having to make an OCSP request every time they want to check the revocation status of a certificate, the server can obtain a short lived OCSP response and 'staple' that to the certificate when presented to the client. This means the client doesn't have to disclose the sites they are visiting to the certificate authority by requesting the revocation status and speeds up the connection process as the client doesn't have do a round trip to the OCSP responder. This results in better performance and privacy for your visitors and it's easy to setup.

 

Cipher Suites

The cipher suites that your server advertises support for is another big factor in how robust your security and performance will be.

 

Perfect Forward Secrecy

Perfect Forward Secrecy (PFS) is a feature offered by certain cipher suites (specifically the key agreement protocol) that prevents data being decrypted even if the private key of the server is compromised. Without the use of PFS, all historic and future traffic can be decrypted if the attacker is able to obtain the private key. The overhead for supporting PFS is minimal and the benefits are great. Looks for cipher suites that contain 'DHE' or 'EDH' to indicate support.

 

Diffie-Hellman Parameters

If you do offer PFS by supporting DHE and/or ECDHE cipher suites, you can add a little more security to your setup by ensuring that you're using a larger key than the typical 1,024 bit default. This needs to be at least the same size key as your TLS certificate (usually 2,048 bit) but it's recommended that you use a 4,096 bit key for maximum security.

 

RC4

The RC4 cipher is almost 3 decades old and as a result is now subject to more and more attacks. The IETF have stated that it must no longer be used and Google have announced they will be dropping support. You shouldn't configure any cipher suites that use RC4.

 

TLS_FALLBACK_SCSV

TLS_FALLBACK_SCSV is a Signalling Cipher Suite Value (the SCSV part) that clients can use to tell a server that the current connection attempt is a fallback from a previously unsuccessful connection attempt. This SCSV got widepsread coverage after POODLE was announced as a means to mitigate protocol downgrade attacks whilst the removal of SSLv3 support was contemplated. Even if SSLv3 support is removed, TLS_FALLBACK_SCSV support should be implemented as it prevents downgrades from newer version of the TLS protocol to older versions.

 

HTTP Strict Transport Security

HTTP Strict Transport Security (HSTS) is a security policy that can be set by a host and will be enforced by most popular browsers. By returning a HTTP response header (strict-transport-security:max-age=31536000; includeSubdomains) a host can tell a browser that it only wishes to be accessed over a secure transport layer, enforcing the use of HTTPS. This will prevent a browser from ever trying to access a site via HTTP from links, direct input from the user or redirects. It will also prevent a user from accessing the site if there are any security warnings by removing the ability to bypass them (a typical action when users don't understand the error message). A great example of this was a widespread attack on internet banking users in Poland. HSTS will also mitigate current forms of SSLstrip attacks.

 

HSTS Preloading

The HSTS response header can only be enforced once the browser has received it. This requires that the client first makes a successful connection to the host issuing the header, leaving the client vulnerable to attack on their very first connection. HSTS preloading resolves this issue by building the HSTS policy of a host directly into the browser. With a list of sites built in, the users is afforded the protection of HSTS at all times, including their first visit and subsequent visits after a cache clear for example.

 

HTTP Public Key Pinning

HPKP allows a host to pin a specific set of public keys that the browser should trust going forwards. This protects the host from Certificate Authorities that might issue rogue certificates in their name. The browser can also send reports when it is presented with a public key that does not match the public key in the HPKP policy. I've published some guidance on setting up HPKP, created a HPKP Toolset to make it easier to test and deploy and setup a subdomain to demonstrate what happens when HPKP validation fails.

 

SHA1 Certificates

I spoke in a previous blog about how Google were sunsetting the SHA1 cryptographic hash and that the Chrome browser would start to issue warnings for certificates that still used SHA1 certificates with an expiry beyond 2015. If you want to avoid receiving warnings in Chrome, any SHA1 certificate with an expiry beyond 2015 needs to be revoked and reissued as a SHA256 certificate. Going forwards it's also a good idea to ensure that any new certificates issued are SHA256 to avoid having to revoke them.

 

Heartbleed

The Heartbleed bug made major headlines in 2014 when it was disclosed as it allowed an attacker to extract the private key of a server from memory. The bug wasn't a flaw in the specification or protocol itself, but a bug in the OpenSSL library that implemented it. The announcement prompted widespread upgrade of vulnerable web servers and key revocation on a massive scale. Ensure you're running the latest version of OpenSSL.

 

Testing It Out

The best way to test all of your configuration changes is using the Qualys SSL Test. The tests are free and take less than a minute or two to perform and you get a very concise, visually pleasing report of all aspects of your TLS configuration. My blog on Getting an A+ rating on the Qualys SSL Test, and the equivalent Windows Version, covers a lot of the technical details of the above and is updated to stay inline with the latest requirements of the Qualys SSL Test. Check it out and feel free to share your results in the comments below!

Scott.
Short URL: