The how and why of good Transport Layer Security (TLS)

Post style: note to myself, but can be freely taken as advice or guidance.

Hat-tip to the National Cyber Security Centre (NCSC, a part of GCHQ) who have a twitter account you should follow and write wonderful guidance like using TLS to protect data and blog posts on why your password expiry policy might be out of date. Their Chief Technology Officer (CTO) also blogged about TLS v1.3 in March 2018.

But first… clarifying scope

This post is aimed at Transport Layer Security (TLS) for Hyper Text Transfer Protocol Secure (HTTPS) on the public web or organisational intranet.

Enterprise certificate problems (including certificate-based authentication) out of scope as managing certificates on a Uninterruptible Power Supply (UPS) or Intelligence Lights Out (iLO) / Dell Remote Access Controller (DRAC) is often needlessly difficult and has a very different risk profile (and user expectation) than public interfaces.

Why encryption-in-transit (particularly HTTPS) is important, if not critical

• Plain-text can be intercepted (someone could read or manipulate content)
• Plain-text cannot be verified (you don’t know if you’re viewing the right content from the right person and on the flip side, if your users are viewing the content you intended them to)
• It promotes privacy as while where the user went can be understood, what they read/saw/did cannot be
• Many data protection authorities around the world will consider you in breach if you’re sending personal information (the definition of which includes email addresses for things like email subscription sign-ups) in plain-text
• It is a strict requirement under Payment Card Industry Data Security Standard (PCI DSS) (which has many sane ideas whether you’re processing card payments or not)
• Encryption-in-transit is the 1st (of 14) Cloud Security Principles
• HTTPS can be faster because many optimisation technologies focus on it (for example, HTTP/2) — check out https://www.httpvshttps.com
• HTTPS is better for business (Google favours HTTPS sites over HTTP ones)
• End-user software/devices warn about unencrypted content and information submissions (Chrome 68 will mark HTTP sites as explicitly ‘not secure’ in the address bar)
• End-user’s sometimes look for the green padlock — (which we can discuss the pros and cons of another day, along with why ‘secure’ is not ‘safe’)

Calling out a common fallacy

Everyone now and again someone says “I don’t need HTTPS, I only serve static content without login.”

In short, my response is “no, you really do.”

I usually do not like making an argument based on consequences but in my view it is rather simple — if the points above don’t convince you: maybe Google downgrading your rankings and browsers warning users your site is insecure and they shouldn’t go there might encourage some reconsideration.

Personally, I have heard this the most from blogger and ‘influencer’ site operators (for some reason I seem to know a lot of people in that line of work and can’t help but fulfil my duty when I meet for a catchup) and I periodically point out that they have an email subscription sign-up on their page and without HTTPS they are not fulfilling their legal obligation to safeguard personal data.

Choosing a certificate authority (CA) / provider

As enterprise is out of scope, so is creating your own.

In short, a ‘good’ one — balance customer service; price; security reputation and posture; technical security change adoption and end-user software/device compatibility. You can also weigh additional features like the number of alternative names supported.

Choose a CA that operates Online Certificate Status Protocol (OSCP) and a Certificate Revocation List (CRL).

Technical security change adoption refers to things like whether they have, or have road mapped Certificate Transparency (CT); SHA-2 and updated ciphers.

It is extraordinarily unlikely that you will ever claim the warranty associated to certificates but I suppose it is useful to consider from a risk perspective if you like that sort of thing.

NCSC have also published guidance on choosing a CA.

One that isn’t going to be distrusted would also be good.

Choosing the validation type

This is worth discussing by itself.

Providers that sell certificates associate identity with certificates and that you can only display identity by increasing certificate validation. In reality, identity and assurance of that is established through an ecosystem of management and having a valid certificate match the domain being connected to is part of that but not the whole story.

• Domain Validated (‘DV’)

Usually email; Domain Name System (DNS) or file-based the certificate will not be issued with your organisational information but just a list (or wildcard) of the domain(s) the certificate is valid for.

A user inspecting it will not see that it is issued to a name — ‘this certificate was issued to medium.com’

These are the cheapest type and generally the quickest to obtain through automated processes (a quick nod to LetsEncrypt and AWS Certificate Manager)

• Organisational Validated Certificates (‘OV’)

Methods vary, but as the ‘in-between’, OU will validate the organisation the ownership of domain and include the information within the certificate.

‘This certificate was issued to Medium, Inc at medium.com’

• Extended Validation (‘EV’)

Usually requires providing evidence that the organisation is formed and registered with an applicable body (for example, Companies House in the UK); the domain is issued/owned by the organisation; the person applying is authorised to do so and address and/or contact information validation.

‘This certificate was issued to Medium, Inc at medium.com… from a more expensive root certificate or intermediate authority.’

My personal view is that these are generally a waste of money and time — they do not provide better/additional cryptographic properties and mostly do not increase your user’s trust of you.

In my view, when OU certificate provides state they are unsuitable for eCommerce use (etc) it is just an up-sell attempt.

Oh to be wild

Wildcard certificates (which can be DV; OV and sometimes EV) can be a simple solution and will be issued as *.domain.tld (cover www.domain.tld; subdomain1.domain.tld; subdomainbravo.domain.tld; 1.domain.tld through to 999.domain.tld and so on).

While this can simplify provisioning; cost and management, you are also limited to protecting a single private key that is now in various places (firewalls; load balancers; web services; FTP servers etc) and so one compromise can force you to rotate all locations (as well as in usual rotations).

The private key should stay private

This is also worth mentioning by itself.

Private keys should stay yours and only yours.

You should only request certificates using Certificate Signing Requests (CSRs) so you maintain full control of the private key generation and management.

When you receive a certificate payload back from the issuer, check it doesn’t contain a private key, as if it does, it means they have used the information from the CSR but have not used it, and issued a private key themselves — which despite all optimism, you should assume has been retained or otherwise assume is no longer just yours. (I’ll just leave this here…)

Ideally your private keys are not stored unencrypted on local disk and you’re using key/secret management to load the private key as required. Not all software supports this, so understand the risks of that — usually its fine, because that usually requires ‘owning’ the service daemon or having a local account on that node with sufficient read privileges.

(Again, this excludes enterprise, as I have never seen a UPS that can create a CSR let alone import a PKCS#12 file the first time without human sacrifice.)

Cryptographic; protocol and signature configurations

• Using the SHA256 hashing function (and keep an eye on SHA512 uptake)
• Only use TLSv1.2 subject to end-user software/device compatibility requirements — after all, what is the point if your users can’t… use
• Seriously think about TLSv1.3
• Use good cipher suites — Qualys have listed their best practice suggestions. Do not use NULL; RC4 or 3DES
• Use (Perfect) Forward Secrecy, if you can
• Use Strong Key Exchange, if you can
• Use OCSP Stapling if you can so the client does not need to contact the OCSP out of bound — this should speed up the TLS connection time

Implementation

• Serve all your content from only HTTPS. Redirect any HTTP query to HTTPS instead of serving a copy of your site via HTTP as well — be nice to your users, http://www.domain.tld/blogs/joel-is-great should not redirect to https://www.domain.tld (the ‘start’)
• Do not mix HTTP and HTTPS traffic and assets — you’ll defeat a lot of the point of doing this and you will be ‘rounded down’ back to insecure

Consider the good practice

Make use of the work that others that have gone before you have learnt (often with much pain) and now provide freely.

• Thoroughly consider implementing HTTP Strict Transport Security (HSTS) — both sending the header and adding the domain to the preload list
• Run the Qualys SSL test and refining based on suggestions
• Consider deploying Content Security Policy (CSP) to (among other things) restrict mixed HTTP and HTTPS content. (It usually quite painful to retrospectively implement CSP.)
• Publish DNS Certificate Authority Authorisation (CAA) records as an administrative step to place a non-technical restriction on certificates being issued by CAs.

Cycling (renewals; revocation or expiry)

Certificates are issued with a fixed expiry date/time and yet even the best among us can forget (twice).

In an ideal ‘business as usual’ world, you will probably think about renewing/replacing (renewing being a continuous extension with the same issuer) your certificate some weeks (I hope) before expiry and simply replace one certificate with another (hopefully with zero downtime).

Certificates can also be revoked (for a variety of reasons, but usually because of compromise or early replacement where the time left is added to the renewal) which means you must have the capability to replace your certificate at any time.

Monitoring

Certificate Transparency can help you see how CAs are behaving and selfishly monitor for issuance or revocations of certificates you care about.

Just like making your stuff is patched (a post on this soon…) you should be monitoring you’re HTTPS configuration and certificate to ensure they are configured as expected (and remain so).

Basic monitoring for certificate configuration issues (simple mistakes, such as not including the intermediate) and expiry can help you count down to renewal periods and avoid facepalm-level mistakes.

You might find other exciting posts in my Medium profile.