TLS Policy

Preamble

Look, it’s got a little lock, your communications are encrypted !

You’re secure !

AND THAT’S A BIG FAT LIE.

You’re not secure, you’re roughly secure as much as the site operator’s security knowledge extends, and that might not mean much.

What’s TLS anyway ?

Let’s keep it short and simple, Transport Layer Security is a protocol for encrypting communication between peers.

While it’s used for other applications such as email, the one you’re most familiar with is HTTP (the famous https:// part of the address).

It basically relies on you (the client) and the remote site (the server) exchanging secret, cryptographic keys, which are subsequently used to encrypt (and sign) messages.

The problem with TLS

One might think “OK so I’ll just turn this TLS thing on and I’ll be fine”, and one would be wrong.

That’s (part of) the problem with TLS, it’s not just a knob you toggle, and then you’re secure.

There are many ways to go about your TLS configuration, and many of them just plain suck.

Indeed there are many subsequent versions of TLS, and they’re all found disparately in the wild, from TLS 1.0 to the newest TLS 1.3.

TLS 1.0 and 1.1 have been all but killed off, which leaves us with TLS 1.2 and 1.3 :

• June 2018 : TLS 1.0 dropped by the PCI SSC
• December 2020 : TLS 1.1 dropped by major Browser vendors

The problems do not stop there though, within different TLS protocol versions you’re still looking at vulnerabilities galore :

• BEAST
• CRIME
• DROWN
• LOGJAM
• LUCKY13
• HEARTBLEED
• POODLE (and variants)
• ROBOT

Even should you patch your implementation to resist these, what about Elliptic Curves, your Key Exchange mechanism, the actual data cipher, or the authentication algorithm ?

Implementation

Covering all the above vulnerabilities and shortcomings would require much more time than you have to read this, so let’s go through the list of how you can create a rather safe implementation.

DNS CAA records

DNS CAA records basically allow your browser to verify which Certificate Authorities can create SSL/TLS certificates for a given site.

They’re a first line of defense for visitors, and site operators definitely should publish them.

HSTS Headers

HTTP Strict Transport Security are HTTP headers that the server sends back with its response, and that instruct your web browser to always use HTTPS (in opposition to unencrypted HTTP) when visiting a given domain or subdomain.

HSTS is easy to implement but doing it wrong could also render your website unreachable.

Make sure you’ve got solid rollout and testing procedures in place :)

TLS 1.3

Released in 2018, TLS 1.3 is the latest evolution of the Transport Layer Security protocol.

It’s faster, it’s safer, and you should ensure you offer it to your visitors.

Key Exchange

Encrypting communications between 2 peers requires that they share a secret, and it’s the Key Exchange’s responsibility to enable the creation of such an initial secret.

There are many different mechanisms, ranging from RSA to ADH, DH, DHE, ECDH and ECDHE (also known as EECDH).

So which should you choose ?

Funnily enough, the more letters, the better.

Elliptic Curve Ephemeral Diffie-Hellman (ECDHE/EECDH) is faster and more robust (the Elliptic Curve part) while providing Forward Secrecy (the Ephemeral part).

Here’s why you care :

• Faster means you need less computing power to serve the same number of clients, which turns into savings
• More robust means your visitors’ communications are less likely to be decrypted one day, which would be bad publicity
• Finally Forward Secrecy makes it harder for data captured today to be decrypted in 8 years, which is a risk in and of itself

ECDHE is widely supported now, and there is no reason at all you shouldn’t offer it to your visitors.

Enable ECDHE ciphersuites in your TLS implementation.

Strong ciphers for data encryption

If you’re using TLS 1.3, you can skip right ahead, it only offers secure ciphers :)

If you also offer TLS 1.2 or lower however, you can easily mess up and weaken your customers’ security.

We won’t delve deep into the pros and cons of this or that cipher in this post, but a good guideline is as follows :

• Offer ChaCha20-Poly1305 first
• Offer AES-128-GCM second
• Offer AES-256-GCM third
• Offer AES-128-CBC fourth
• And fallback to AES-256-CBC last

While AES with a 128-bit encryption key might seem weaker than AES with a 256-bit key (the more the better right ?), the latter is the subject of related-keys attacks that actually make it easier to crack than the 128-bit variant. Go figure 🤷‍♂️

As for ChaCha vs GCM vs CBC, here’s a quick rundown as to why :

• ChaCha has no known vulnerabilities or defects at the time
• GCM fails catastrophically under the right/wrong conditions
• CBC mode has been broken for years and can never be fixed

AES in GCM mode is so dangerous that cryptographers around the world are directly quoted saying so, slide 11 of this presentation.

Wrap it all up in a congruent configuration

Let’s sum up our ideas here :

• Publish DNS CAA records
• Publish HSTS headers
• Offer TLS 1.2 and 1.3
• Prefer ciphersuites with an ECDHE key exchange
• Prefer ciphersuites with ChaCha20, then AES-GCM, then AES-CBC
• Prefer 128-bit AES to 256-bit AES

And ensure you’re good by testing

You’ve done your homework, you’ve adjusted your configurations (you did warn your customers beforehand, like, WAY ahead right ? This is no small change !), now you need to ensure your configuration reflects what you wanted to implement.

There are several free tools to verify your TLS configuration, the most known of which is Qualys’ SSL Labs.

Alternatively, Immuniweb also offers a similar tool.

Finally, your more tech-savvy operators might prefer Testssl.sh.

Looking Good

In the end, you should be looking pretty good.

It’s not all about the pretty colors though, expect your customers to run these scans on your own website !

Immuniweb’s SSL Test liking what it sees.

Qualys Labs’ SSL Test agreeing very much.

Takeaways

SSL and TLS are very complex monsters.

The opportunity to royally mess up lies around every corner, and that’s a literal (hello AES GCM).

As a CEO, CTO, or Compliance Officer, you should ask your teams what configuration was implemented to protect your customers’ communications, and why it was done this way.

Most importantly, you need to ensure your staff remain on top of the most recent developments in the fields.

After all, attacks land one day and are exploited the next (if not the same or even before).

Still not convinced ?

Head over to ARS Technica’s writeup on an actual attack leveraging Heartbleed.