Lead Image © Yevgeniya Ponomareva, Fotolia.com

Lead Image © Yevgeniya Ponomareva, Fotolia.com

SSL/TLS best practices for websites

Keeping Secrets

Article from ADMIN 23/2014
By
SSL and TLS are very complex technologies. If you want to avoid wading through cryptography manuals to harden your HTTPS web server, read on for practical recommendations on establishing, securing, and optimizing your SSL/TLS configuration.

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.

Figure 1: Only the Firefox browser can remember a self-signed certificate and guarantee that it has not changed.

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

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy ADMIN Magazine

SINGLE ISSUES
 
SUBSCRIPTIONS
 
TABLET & SMARTPHONE APPS
Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • What's left of TLS
    Numerous attacks have rocked the security of SSL/TLS encryption in recent years. Newer standards would remedy this, but they are not widely used.
  • Transport Encryption with DANE and DNSSEC
    Those who think that enabling STARTTLS in the mail client will make their mail traffic more secure are wrong. Only those who bank on DANE can be sure that a mail server or a firewall will not switch off encryption in transit.
  • Many approaches help secure a web server
    We submit an Apache web server to the Qualys SSL Server Test and look at how to protect against data theft with a combination of TLS by way of Let's Encrypt, SELinux or AppArmor, a firewall, and restraining your web server's verbosity.
  • TLS 1.3 and the return of common sense
    After a decade in service, TLS 1.2 is showing many signs of aging. Its immediate successor, TLS 1.3, has earned the approval of the IETF. Some major changes are on the way.
  • Setting up SSL connections on Apache 2
    To spoil the day for lurking data thieves, Apache administrators only need three additional directives – and a handful of commands.
comments powered by Disqus