SSL/TLS best practices for websites
Keeping Secrets
SSL and its successor TLS are a never-ending source of surprises – even for me, and I have been using these encryption technologies since the early days of Netscape Navigator. When you think you finally understand SSL, a new mystery opens up, and you find yourself delving the depths again.
Most admins don't have time for long searches. Admins want to set up a secure HTTPS website as quickly as possible and turn to the next task. This article provides advice on using SSL for web practitioners, and I'll even include some sample files for Apache and Nginx.
1. Algorithms and Key Lengths
Currently, TLS supports three key algorithms: DSA is dead; the future belongs to elliptic curve cryptography with ECDSA, but older clients do not support it, so the standard also supports RSA for now.
The key length of 2048 bits for RSA keys, or 256 bits for ECDSA, should be sufficient for most purposes. Keys of this length offer 112 or 128 bits of encryption strength. If you want a future-proof solution, you can opt for a 3072-bit RSA key, which also gives you 128 bits of encryption.
2. KeyManagement
What is more important than the length of the key in practice, however, is the way the admin handles the keys. Much evidence suggests that the most successful attacks on SSL have not actually cracked the encryption but simply avoided it. If you can break into a server to steal the private keys, or otherwise gain access to them, you do not need to break your teeth on the cryptography.
The private keys must remain secret. Only a small group of employees should have access to these valuable files – just enough to ensure smooth operations.
Additionally, the admin should protect the keys with a password and enter a passphrase when generating them. These precautions reduce the risk if a backup of the system gets into the wrong hands.
The person in charge should keep a copy of the keys in a safe place. Losing the key for a single server is not too bad, because a new one can be easily generated. But, if you operate your own certificate authority (CA), keys are extremely complex to replace.
3. TheCertificate
The SSL certificate should come from a reputable certification authority, but you do not need to put too much thought into the choice. In the case of Domain Validated (DV) certificates, the lowest price wins. If your site has many users, certificates with extended validation (EV) leave a better impression, but they hardly increase the technical security.
The certificate needs to contain all the hostnames – including the versions with and without the WWW prefix, as in, example.com and www.example.com . The "Key and Certificate Sharing" box provides more instructions on using multiple hostnames.
Key and Certificate Sharing
Where multiple sites share a key and certificate to reduce the procurement and maintenance costs, there is also a single IP address with multiple virtual hosts for the different sites. You can share a certificate by adding the desired hostnames to it. Another option is to use a single wildcard certificate for an unlimited number of subdomains.
Caution is advisable with key and certificate sharing if you want to avoid causing security problems. Sharing is not suitable, for example, for groups of sites that need to support different teams or meet different security requirements. If just one of the sites were compromised, the key could be used for attacks against everyone else.
The certification chain needs to be complete. Broken chains are among the most common deficiencies. Some browsers can handle a broken chain, but the problem can lead to hard-to-understand errors.
The CA should sign its certificates using SHA-256. It also needs to embed revocation information in the form of certificate revocation lists (CRLs) and an online certificate status protocol (OCSP). If you want to play CA yourself, read the box titled "Self-Signed or Private CA."
Self-Signed or Private CA
This article assumes the certificate comes from a public CA. In addition, you have the option of signing the certificate yourself or operating your own certification authority, which supplies the server with certificates.
These three practices are suitable for various usage scenarios. For a public website, only a certificate from a public certification authority is possible.
Using a self-signed certificate implies many restrictions; it can only be used securely in conjunction with the Mozilla Firefox browser. Only the Firefox allows the user to permanently save exceptions for such certificates (Figure 1). Once you save the exception, you're secure for all later visits to the same site.
Other browsers require re-confirmation every time you visit. If you do not check the fingerprint of the certificate every time – and who does? – you are taking a big risk.
For these reasons, it is better to operate your own certificate authority if you do not want to buy a certificate from a public CA. A full certificate authority is initially more expensive than a self-signed scenario, but as soon as the infrastructure is available and the root key is distributed to all users, it works as reliably as the rest of the PKI world.
Buy this article as PDF
(incl. VAT)