This page is intended to be a handy quick reference guide for HTTPS configuration.
No versions of the SSL protocol are acceptable for use whilst, currently, all versions of the TLS protocol are acceptable for use. It's worth nothing that the PCI SSC will not permit the use of TLSv1 after 30th June 2018 (source).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2
SSLProtocol All -SSLv2 -SSLv3
Choosing ciphers suites can be difficult and their names may look complex but they can be easily broken down into their components. Take the following suite:
The components are:
TLS - the protocol used ECDHE - the key exchange mechanism ECDSA - the algorithm of the authentication key AES - the symmetric encryption algorithm 128 - the key size of the above GCM - the mode of the above SHA256 - the MAC used by the algorithm
Key exchange mechanisms
You should only support suites that use ECDHE and DHE (also referred to as EECDH and EDH) for the key exchange. The EC variant is faster and both offer Perfect Forward Secrecy (PFS) which is essential. An example of supporting both ECDHE and DHE with ECDHE preferred.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
Note: TLSv1.3 will only support PFS capable key exchange.
The vast majority of the web will use RSA for the authentication key as it's widely supported but ECDSA is considerably faster (source). You can serve both RSA and ECDSA certificates for the best of both worlds (tutorial). Only support suites that are appropriate to your circumstances by checking for RSA and/or ECDSA in the authentication segment.
With RSA certificate:
With ECDSA certificate:
With hybrid RSA and ECDSA certificate:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
In the above example AES_128_GCM forms the cipher. AES is the preferred algorithm and using a key size of 128bits is acceptable. You can prefer 128bit keys over 256bit keys for performance reasons. The GCM segment is the mode of the cipher and indicates that this is an AEAD (Authenticated Encryption with Associated Data). GCM suites should be prioritised over non GCM suites. An example with the GCM and non-GCM versions of the same suite.
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_SHA256 TLS_ECDHE_RSA_WITH_AES_256_SHA384
Note: TLSv1.3 will only support AEAD suites.
Prefer server order
When we specify the list of ciphers in our preferred order, we need to tell the server to enforce that order or it won't.
HTTP Strict Transport Security
HSTS is a HTTP response header that allows you to configure your visitor's browser to only communicate with you via HTTPS, no matter what happens. No deployment of HTTPS is complete without HSTS being configured. You can read more in HSTS - The missing link in Transport Layer Security and I have quite a few articles covering HSTS.
add_header Strict-Transport-Security "max-age=600; includeSubDomains";
Header always set Strict-Transport-Security "max-age=600; includeSubDomains"
As you grow more confident with your policy you increase the size of max-age and also consider HSTS Preloading.
The Online Certificate Status Protocol is used to check the revocation status of a certificate. The browser makes a request to the CA to check the status of the certificate, an OCSP request, and the CA responds with an OCSP response saying the certificate is valid or revoked. This puts a burden on the client to do a DNS lookup for the CA and then the overhead of the OCSP request and also leaks the site that the client is visiting to the CA, which is a huge privacy issue. To solve this problem, OCSP Stapling was created. When OCSP Stapling is setup, the server will do the OCSP request and then cache the OCSP response on the server. It will then 'staple' this to the certificate and send it to the client, removing the performance burden and privacy issues.
There are certain performance advantages that become available to you once you serve your content over a secure connection.
HTTP/2 is the next version of the HTTP protocol and comes with significant performance advantages. You can read more in HTTP/2 is here! and see my statistics that how HTTP/2 support is already widespread in Monitoring HTTP/2 usage in the wild.
Brotli is a new compression algorithm that has the potential to outperform gzip and also supports static compression, so you don't need to compress assets on the fly. I wrote an article about Brotli Compression that contains details on the algorithm and how to build it into Nginx.
Google recently announced that HTTPS will be used as a ranking signal so serving over HTTPS will increase your page ranking.
The infamous SSL Labs, check your config
Check your headers for things like HSTS and HPKP
Strong configurations for common servers
Some guidance from Google on moving to HTTPS
How Yelp migrated to HTTPS
Mozilla HTTPS config generator
Configuring features like HSTS and HPKP can be dangerous, be sure you know what you're doing. Please do not copy and paste config from the internet!
Not that there is much we can do about it, but some security features can also be used for bad things. It could be a good idea to monitor for things like this.