Bulletproof

TLS Guide

Last update: Fri May 31 04:13:11 BST 2024 (build 127)

Bulletproof TLS Guide

Ivan Ristić
Bulletproof TLS Guide
by Ivan Ristić
Version 2023.1 (build 127), published in May 2024.
Copyright © 2023 Feisty Duck Limited. All rights reserved.

Feisty Duck Limited

www.feistyduck.com
contact@feistyduck.com

Production editor: Jelena Girić-Ristić

Copyeditor: Melinda Rankin

All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or
by any means, without the prior permission in writing of the publisher.
The author and publisher have taken care in preparation of this book, but make no expressed or implied warranty of any kind
and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in con-
nection with or arising out of the use of the information or programs contained herein.
Table of Contents
Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v
1. Configuration Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Private Keys and Certificates 1
Use Strong Private Keys 1
Secure Your Private Keys 1
Choose the Right Certification Authority 3
Prevent Certificate Warnings 4
Control Key and Certificate Sharing 4
Think Chains, Not Certificates 5
Deploy Certification Authority Authorization 5
Automate Certificate Renewal 5
Use Certificate Transparency Monitoring 6
Configuration 6
Use Secure Protocols 6
Use Forward Secrecy 7
Use a Strong Key Exchange 8
Prioritize the Best Cipher Suites 8
Use Secure Cipher Suites 8
Ensure Ticket Keys Are Rotated 10
Mitigate Known Problems 11
Supporting Legacy Platforms 11
HTTP and Application Security 12
Encrypt Everything 12
Secure Cookies 13
Use Strict Transport Security 14
Deploy Content Security Policy 15
Disable Caching 15
Be Aware of Issues with HTTP Compression 15
Understand and Acknowledge Third-Party Trust 16

iii
 Performance 16
Don’t Use Too Much Security 16
Enable Session Resumption 17
Optimize Connection Management 17
Enable Caching of Nonsensitive Content 18
Use Fast Cryptographic Primitives 18
Validate and Monitor 19

iv
Preface
Our journey to achieving good network transport security has been long and fraught with
difficulties. In the 1990s—when this story began with the early versions of SSL and the
Netscape browser—the main challenges were lack of good encryption standards, restric-
tions on the export of cryptography, and insufficiently powerful computer chips. It took us a
good three decades to work through these problems. During that period, a few things im-
proved. The export restrictions went away and computers became faster. A few other things
became worse, chiefly because the web platform continued to evolve organically without
sufficient thought given to security.
But we collectively kept chipping away at the problems, eventually figuring out what secure
network protocols should look like and what kind of security we’d like to have. We figured
out that we don’t have to configure each and every server individually and that we can in-
stead rely on the secure and sane defaults now available. We also figured out that we don’t
need to manually rotate every single certificate and that automation can achieve much bet-
ter results with far less time and effort.
At some point, the threads of our progress started to converge, and there is now a feeling
that transport security is within our reach. Your reach. Things are significantly better, but
we’re not quite there just yet. The field remains complex and filled with many moving parts
that need to be accounted for. Some assembly is required.
The guide that’s in front of you has been designed to get you over the finish line. If you fol-
low the assembly instructions specified herein, you will be able to deploy TLS and PKI with
confidence. Yes, there will still be things you’ll need to figure out, but the path should at
least be predictable and easy to follow.
I have been involved with SSL/TLS and PKI in some form since the early days, but especial-
ly in the last two decades, focusing my efforts on what I sometimes like to call the last mile
of transport security. My work consisted chiefly of researching the field and communicating
my findings in various forms.
For example, SSL Labs, one of my earlier projects, provided free assessments of SSL/TLS and
PKI configuration and ended up being fairly successful. It happened to be right there when

v
the world decided to start caring about such things, roughly around the time of Heartbleed.
(Look it up.) In the end, SSL Labs helped improve the security of millions of web sites, and
I’m very happy with that. These days, you’re probably better off taking a look at my follow-
up project, Hardenize, which helps with problems related to a wider range of network and
security standards.
Most of what I learned has been recorded in my book Bulletproof TLS and PKI, which I’ve
been continuously writing and publishing for about a decade now. You should definitely
read it if you’re involved with computer security, software development, or system adminis-
tration. But even if you don’t have time for that, this guide will tell you everything you need
to know. In fact, this guide has been taken directly from my book and published stand-alone
for the very purpose of being easily available to a large audience.

—Ivan Ristić

vi Preface
1 Configuration Guide
Private Keys and Certificates
Private keys are the cornerstone of TLS security, but also one of the easier things to get
right. These days, CAs aren’t allowed to issue certificates against weak keys. But despite fre-
quent focus on key sizes, the weakest link is usually key management, or the job of keeping
the private keys private. We’ll touch upon that in this section. Equally important are certifi-
cates, which build upon the keys with important metadata, such as the permission to asso-
ciate a certificate with a particular domain name.

Use Strong Private Keys

For the certificate private key, you have a choice of RSA or ECDSA algorithms. The easy
option is to use RSA keys because they are universally supported. But at 2,048 bits, which is
the current minimum, RSA keys offer less security and worse performance than ECDSA
keys.
At the same time, ECDSA is the algorithm of the future and RSA is slowly being left behind.
A 256-bit ECDSA key provides 128 bits of security versus only 112 bits for a 2,048-bit RSA
key. At these sizes, in addition to providing better security, ECDSA is also significantly
faster.
By now, ECDSA is very widely supported and the devices that don’t support it are very rare
and probably support only obsolete security protocols. If you’re still concerned about inter-
operability, it’s possible to deploy services with dual certificates, thus supporting RSA and
ECDSA keys simultaneously. The only disadvantage of this setup is the increased mainte-
nance overhead. Some managed providers do this automatically and thus make it trivial.

Secure Your Private Keys

Although we spend the most time obsessing about key size, issues surrounding key manage-
ment are more likely to have a real impact on your security. There is ample evidence to sug-

1
gest that the most successful attacks bypass encryption rather than break it. If someone can
break into your server and steal your private key or otherwise compel you to disclose the
key, why would they bother with brute-force attacks against cryptography?
Keep your private keys private
Treat your private keys as an important asset, restricting access to the smallest possi-
ble group of employees while still keeping the arrangements practical. Some CAs of-
fer to generate private keys for you, but they should know better. The hint is in the
name: private keys should stay private, without exception.
Think about random number generation
The security of encryption keys depends on the quality of the random number gener-
ator (RNG) of the computer on which the keys are generated. Keys are often created
on servers right after their installation and rebooting, but at that point the server
might not have sufficient entropy to generate a strong key. It’s better to generate all
your keys in one (offline) location, where you can ensure that a strong RNG is in
place.
Password protect your keys
Your keys should have a passphrase on them from the moment they are created. This
helps reduce the attack surface if your backup system is compromised. It also helps
prevent leakage of the key material when copying keys from one computer to another
(directly or using USB sticks); it’s getting increasingly difficult to safely delete data
from modern file systems.
Don’t share keys among unrelated servers and applications
Sharing keys is dangerous: if one system is broken into, its compromised key could be
used to attack other systems that use the same key, even if they use different certifi-
cates. Different keys allow you to establish strong internal access controls, giving ac-
cess to the keys only to those who need them.
Change keys regularly
Treat private keys as a liability. Keep track of when the keys were created to ensure
they don’t remain in use for too long. You must change them after a security incident
and when a key member of your staff leaves, and you should change them when ob-
taining a new certificate. When you generate a new key, you remove the old key as an
attack vector. This is especially true for systems that do not use or support forward
secrecy. In this case, your key can be used to decrypt all previous communications, if
your adversary has recorded them. By deleting the key safely, you ensure that it can’t
be used against you.
Your default should be to generate a new private key with every certificate renewal.
Systems with valuable assets that do not use forward secrecy (which is not advisable)
should have their keys changed at least quarterly.

2 Chapter 1: Configuration Guide

 Store keys safely
Keep a copy of your keys in a safe location. Losing a server key is usually not a big
deal because you can always generate a new one, but it’s a different story altogether
with keys used for intermediate and private CAs and keys that are used for public key
pinning.
Generating and keeping private keys in tamper-resistant hardware is the safest ap-
proach you can take, if you can afford it. Such tools are known as Hardware Security
Modules (HSMs). If you use such a device, private keys never leave the HSM and, in
fact, can’t be extracted. These days, HSMs are commonly available as cloud services.
They don’t provide the same level of security as tools that you might be able to host in
your data centers, but they’re a great improvement nevertheless.

Choose the Right Certification Authority

For a small site that needs only a simple domain-validated certificate, virtually any CA will
suffice. You can do what I do—just buy the cheapest certificate you can find. Or, if you can
automate certificate renewal (highly recommended), just get your certificates for free from
Let’s Encrypt and other similar providers. After all, any public CA can issue a certificate for
your web site without asking you; what’s the point of paying more if you don’t have to? If
you have complex requirements, you may want to explore the commercial options, at which
point you should take your time and select a CA that meets your requirements.
Features
At a minimum, you will want to work with a CA that supports both RSA and ECDSA
certificate keys. If you care about revocation, your chosen CA must support OCSP
certificate revocation checking backed by robust network availability and perfor-
mance.
We now finally have end user standards for automated certificate issuance (Automatic
Certificate Management Environment, or ACME for short), and you should use them
wherever possible. For this, you’ll need a CA that supports automation.
Focus and expertise
PKI is a field that requires deep expertise and dedication; mistakes are easy to make.
If you’re going to be relying on a CA for a critical function, you may as well choose an
organization that’s serious about it. This is not quite easy to quantify, but you should
examine the selected CA’s history, staff, and business direction. It’s best to work with
CAs for which certificate issuance is the core part of their business.
Service
At the end of the day, it’s all about the service. The certificate business is getting more
complicated by the day. If you don’t have experts on your staff, perhaps you should
work with a CA on which you can rely. Costs matter, but so do the management in-

Choose the Right Certification Authority 3

 terfaces and the quality of the support. Determine what level of support you will re-
quire from your CA, and choose an organization that will be able to provide it when
you need it.
You should be aware that if you’re getting your certificates from only one CA, they are your
single point of failure. If your deployments are sufficiently important to justify the addition-
al effort, consider getting your certificates from two different CAs at the same time. With
overlapping certificate lifetimes, you will always have a backup certificate to use if the pri-
mary fails for whatever reason.

Prevent Certificate Warnings

Certificate warnings are not unusual and happen for a number of reasons, but all of them
can be prevented. The world of technology is confusing enough; you shouldn’t add to the
cognitive load your users are already experiencing. If you don’t pay attention, you will con-
fuse them and weaken their confidence in your technical abilities. In addition, for web sites
that disable certificate warnings via HTTP Strict Transport Security (HSTS), misconfigured
certificates lead to immediate breakage.
Getting certificates right is not very difficult, especially when compared to everything else
you need to do to ensure security. With correct initial configuration, renewal automation,
and monitoring, you will ensure a smooth experience for your users.
You should pay attention to ensure you have valid certificates for all different domain names
and subdomains. As a rule of thumb, keep track of every DNS name that points to your
properties and get certificates for all of them. For example, if your main web site is at
www.example.com, the domain name example.com should also have a valid certificate, even
though this variant will be configured only to redirect your users to the main location. It’s
easy to use just one certificate for all of this.

Control Key and Certificate Sharing

In PKI, private keys and certificates can be shared among properties. This practice is not
necessarily insecure, but only if it’s done correctly. If in doubt, don’t share. Don’t use the
same certificate on multiple properties; don’t even put different hostnames on the same cer-
tificate. With this approach, each property will be independently secured.
The main issue with sharing is that if one property is compromised, the other ones in the
same group can also be attacked. If you have a group of properties that are all managed by
the same team and are all part of the same system, sharing is not necessarily bad. On the
other hand, multiple teams and multiple distinct properties sharing certificates is always
bad.

4 Chapter 1: Configuration Guide

Wildcard certificates have their place. For example, they are best used by a single property
when you need to support an arbitrary number of subdomains, usually one per customer.
Avoid them otherwise.

Think Chains, Not Certificates

Although we spend a lot of time talking about server certificates, in practice we work with
certificate chains. Because server operators have to configure these chains manually, mis-
takes are common. Most often, you will see TLS servers with just the leaf certificate or a set
of certificates that don’t actually form a valid chain.
An invalid certificate chain may render the entire TLS connection invalid, leading to a
browser warning. To make things worse, this problem is often difficult to diagnose because
some browsers try hard to fix it and others don’t. This is a good example of a problem that
should be diagnosed by your monitoring tool.

Deploy Certification Authority Authorization

Certification Authority Authorization (CAA) is an evolving security standard that enables
you to restrict what CAs are allowed to issue certificates for your properties. CAA is deliv-
ered via DNS. When a new certificate is requested, the CA must look for a CAA policy on
the affected hosts and verify that they have permission to proceed. If they don’t, the issuance
fails.
In the following example configuration, Let’s Encrypt is allowed to issue nonwildcard cer-
tificates (issue), DigiCert and Entrust are allowed to issue wildcard certificates (issuewild),
no CA is allowed to issue S/MIME certificates (issuemail), and there is an advertized email
address to use to report issuance problems (iodef):
example.com. CAA 0 issue "letsencrypt.org"
example.com. CAA 0 issuewild "digicert.com"
example.com. CAA 0 issuewild "entrust.com"
example.com. CAA 0 issuemail ";"
example.com. CAA 0 iodef "pki@example.com"

CAA is a very useful addition to the defense arsenal. Even a policy that allows many CAs is
helpful as a way of reducing the attack surface, compared to the default, which allows all
CAs. Deploying CAA may be difficult in complex environments because a policy set on the
apex domain name applies to all subdomains.

Automate Certificate Renewal

When it comes to certificate lifetimes, renew yearly if you’re still doing this work by hand.
Aim to automate certificate renewal, then switch to quarterly issuance. Because it is current-

Think Chains, Not Certificates 5

ly impossible to revoke compromised certificates reliably, certificates with shorter lifespans
are effectively more secure.
Don’t leave it until the last moment to initiate the renewal. In fact, it’s better if you renew
earlier—for example, about a month before the current certificate expires. Doing so will
provide you with a margin of safety should the new issuance fail for whatever reason. Many
things can go wrong, among them issues with the CA itself or issues with the CAA configu-
ration.
For best results, deploy new certificates to production about two weeks after they are issued.
This practice (1) helps avoid certificate warnings for some users who don’t have the correct
time on their computers and also (2) avoids failed revocation checks with CAs that need
extra time to propagate their new certificates to their OCSP responders.

Use Certificate Transparency Monitoring

Since 2018, all public certificates for web sites are recorded via Certificate Transparency
(CT), a Google-led effort to improve transparency of the PKI. There are specialized moni-
toring services (e.g., Hardenize) that observe all recorded certificates and make it possible to
find all certificates issued for your properties. CT monitoring is an easy and cost-effective
way to understand issuance in complex environments (in terms of who is doing what and
where), enforce policy, and catch unexpected certificates or even misissuance.

Configuration
When it comes to protocol configuration, your choices are likely to be influenced by a com-
bination of security, interoperability, and regulatory requirements. In the ideal world, focus-
ing on security alone, you would allow only TLS 1.3 and disable all other protocol versions.
But that works only in well-understood environments; although modern browsers support
TLS 1.3, many other products and tools still don’t.

Use Secure Protocols

A web site intended for public use needs to support TLS 1.3 and TLS 1.2 at minimum. It’s
very likely that you don’t need TLS 1.1 and TLS 1.0; modern browsers no longer support
them. The remaining protocols, SSL 3 and SSL 2, are both obsolete and insecure.
• SSL 2 is completely broken and must not be used. This is the first–ever protocol version
and is so bad that it can be used to attack even well-configured servers that use over-
lapping certificates or private keys (the so-called DROWN attack).

6 Chapter 1: Configuration Guide

 • SSL 3 is better, but still insecure when used with HTTP because of the POODLE attack.
It’s also very weak when used with other protocols. It’s obsolete and lacks essential se-
curity capabilities. Don’t use.
• TLS 1.0 is a legacy protocol that lacks essential security capabilities. Modern clients no
longer support this protocol version, but there are still old clients out there that need it.
TLS 1.0 is vulnerable to the BEAST attack, although most browsers have deployed mit-
igations as a workaround.
• TLS 1.1 is also a legacy protocol that lacks modern capabilities. There are hardly any
clients that support this version but don’t support TLS 1.2.
• TLS 1.2 is a relatively modern protocol that can provide good security, but it supports
both bad and good cryptographic primitives. It can be used securely with some effort.
This protocol version is necessary in order to support a wide range of customers.
• TLS 1.3 is a completely reworked revision of TLS that supports only secure primitives.
This protocol version, which modern browsers support, should be what protects most
of your network communication.
If you need to support very old clients and wish to continue to use TLS 1.0, base your deci-
sions on evidence, not fear. This protocol version is no longer considered secure, so tread
carefully.

Use Forward Secrecy

Forward secrecy (also known as perfect forward secrecy) is a feature of cryptographic proto-
cols that ensures that every communication (e.g., a connection) uses a different set of en-
cryption keys. Such keys are called ephemeral because they are discarded after they are no
longer needed. Ephemeral connection keys do not depend on any long-term keys—for ex-
ample, the server key. When there is no forward secrecy, an adversary who can record your
network traffic and later obtain the server key can also decrypt all past communications.
SSL and TLS initially used only the RSA key exchange that doesn’t support forward secrecy.
To fix that, the ephemeral Diffie-Hellman (DHE) and Elliptic Curve Diffie-Hellman (ECD-
HE) key exchanges were added over time, along with some protocol improvements in TLS
1.3. Don’t be confused by the fact that RSA can be used for key exchange and authentica-
tion; the former is bad, but the latter is fine.
In TLS 1.2 and earlier protocol versions, the key exchange (and thus forward secrecy) is
controlled via cipher suite configuration. Therefore, you want to ensure that all enabled
suites embed the keywords DHE and ECDHE. In TLS 1.3, all suites support forward secrecy; the
RSA key exchange is no longer supported.

Use Forward Secrecy 7

Use a Strong Key Exchange
In recent years, the DHE key exchange fell out of fashion, so much so that modern clients
no longer support it. As a result, there is only one widely supported secure option for the
key exchange, and that’s ECDHE. Although DHE suites do have some issues, they are not
likely to be a problem in practice if used only as fallback. You shouldn’t use the RSA key
exchange (not to be confused with RSA authentication) because in that case you lose for-
ward security.
For key exchange to be secure, ECDHE and DHE have to be used with secure parameters.
For ECDHE, the parameters are called named curves and only two are practical: X25519 and
P-256 (also known as sec256r1). For DHE (if using), ensure the parameters provide 2,048
bits of security. Some server software provides secure DHE parameters out of the box; with
others, you’ll have to provide your own.
If long-term security is of concern, follow the efforts to transition to post-quantum cryptog-
raphy. New, quantum-resistant key exchange standards are in the process of being devel-
oped and tested.

Prioritize the Best Cipher Suites

In TLS, servers are in the best position to determine the most secure communication option
to use with the connecting clients. That’s because the first step of the TLS handshake in-
volves the client sending a list of supported features. What remains is for the server to
choose what feature to proceed with.
Unfortunately, some platforms don’t actively choose the best option, instead resorting to
choosing the first one offered by clients. For best results, check what your platform does and
enable server preference wherever possible. In general, avoid platforms that don’t support
server preference enforcement as it may not be possible to configure them securely in a gen-
eral case.

Use Secure Cipher Suites

In TLS, cipher suites are the most visible aspect of server configuration. Usually a lot of
effort goes into understanding what options are available, secure, and required to achieve
secure communication. Determining what cipher suites to use has traditionally been diffi-
cult; over time, the TLS protocol accumulated a very large number of suites, most of which
are considered insecure or inadequate today.
On the positive side, TLS 1.3, the most recent incarnation of the TLS protocol, supports on-
ly a handful of suites, and all of them are secure. If you base your configuration on this pro-
tocol version, all connections with clients that also support it will be secure with ease. You
should lead with the following three suites (which are usually enabled by default anyway):

8 Chapter 1: Configuration Guide

 TLS_AES_128_GCM_SHA256
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_256_GCM_SHA384

When it comes to TLS 1.2, you should rely on cipher suites that provide strong key ex-
change, forward secrecy, and AEAD (authenticated encryption with associated data) encryp-
tion of 128 bits. Use AES and ChaCha20 encryption algorithms. Your configuration can
continue to utilize non-AEAD suites, but only to support very old clients, if that’s necessary.
Don’t use anything else unless you’re a cryptographer and know what you’re doing.
The preceding recommendations, translated to specific TLS 1.2 suites, yields the following:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256

This configuration is designed with both security and performance in mind. It supports
both ECDSA and RSA keys, with priority given to the former, which is faster. It also in-
cludes more suites than strictly necessary in order to support a wider range of clients.
If you’re using OpenSSL, the following configuration is exactly the same but uses the non-
standard suite names that OpenSSL will understand:
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-ECDSA-AES128-SHA
ECDHE-ECDSA-AES256-SHA
ECDHE-ECDSA-AES128-SHA256
ECDHE-ECDSA-AES256-SHA384

Use Secure Cipher Suites 9

 ECDHE-RSA-AES128-GCM-SHA256
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-RSA-AES128-SHA
ECDHE-RSA-AES256-SHA
ECDHE-RSA-AES128-SHA256
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES128-GCM-SHA256
DHE-RSA-CHACHA20-POLY1305
DHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES128-SHA
DHE-RSA-AES256-SHA
DHE-RSA-AES128-SHA256
DHE-RSA-AES256-SHA256

I recommend that you always configure OpenSSL with an explicit list of desired suites, as
indicated earlier. This approach is the simplest and provides great visibility into exactly what
is enabled. With OpenSSL, it’s also possible to use the legacy, keyword-based configuration
approach, but that leads to opaque configurations that are difficult to understand and often
end up doing the wrong thing.

Ensure Ticket Keys Are Rotated

In TLS, session resumption is implemented using one of two approaches. The original ap-
proach was to have the server keep the state in persistent storage. Later, session tickets were
added, and they work like HTTP cookies. Session state is packaged into a binary blob, en-
crypted, and sent back to the client to store and send with all subsequent connections.
When session tickets are used, the security of all connections depends on the main ticket
key. This key is used to safely encrypt and decrypt session tickets. The security of the ticket
key is an area in which current server software doesn’t provide adequate controls. Most ap-
plications that rely on OpenSSL use implicit ticket keys that are created on server startup
and stay the same for the duration of the process. If the process stays up for weeks and
months, so does the ticket key. Backdooring applications is relatively easy for skilled attack-
ers; you can inject a static, never-changing ticket key to give you the ability to decrypt all
communication. The most secure deployments of TLS configure ticket keys explicitly and
rotate them on a predetermined schedule—for example, daily.
Session ticket security is very important to get right if you’re deploying TLS 1.2. In this situ-
ation, knowing the ticket key is all you need to decrypt past communications. TLS 1.3
brought some much-needed improvement in this area. This updated protocol version uses
session tickets for authentication, but has an option (enforced by all modern browsers) to
perform an ephemeral Diffie-Hellman handshake on all resumed connections. The end re-
sult is that knowing the ticket key is no longer sufficient for passive decryption, making it a
much smaller attack vector.

10 Chapter 1: Configuration Guide

Mitigate Known Problems
There was a period of time when it was common to learn about new protocol issues, but
that now seems to be behind us. At some point we stopped finding new problems; the ones
we know about were largely fixed. Then TLS 1.3 came along, which made things much bet-
ter still. Critical issues at the protocol level are not so common today, but it’s generally ac-
cepted that security always deteriorates over time. For that reason, it’s a good practice to be
aware of what’s going on. At this point in time, the most likely problems you will encounter
are implementation issues in libraries and server software. Apply patches promptly when
they become available.

Supporting Legacy Platforms

Sometimes you’ll find yourself needing to support legacy clients that don’t have the latest
and greatest security features. In this case, you will need to reach out for, and enable, certain
components that are not ideal but are still acceptable for use in exceptional situations. It
could be that the risk of the exploitation is low or that the service is not that valuable, or
perhaps you have mitigation measures in place. If you are in this situation, this section is for
you; I will outline here some of those imperfect but palatable legacy features.
The good news is that it’s generally possible to deploy strong and weak elements at the same
time, relying on the TLS negotiation features and server configuration to ensure that indi-
vidual connections use the best commonly supported features. This means that those weak
elements in your configuration will be used only as a last resort.

Note
If you have to resort to using some of these weak encryption components in pro-
duction, consider splitting your systems into those that are well-configured and
those that are intended to serve your legacy clients. Structuring your deployments
like that will help you minimize the risk.

RSA private keys

The ECDSA algorithm is gaining in popularity on account of its speed, but you will
often find that it’s not supported by some old clients. In this case, fall back to the RSA
algorithm. If you care about performance, deploy with two certificates, using both
ECDSA and RSA at the same time.
TLS 1.1, TLS 1.0, SSL 3, and SSL 2
Very old user agents won’t support TLS 1.2, so you may need to enable TLS 1.0 for
them. This is not terrible and you may find that my recommended suite configuration
works for you. If you’re considering SSL 3, you’re dealing with ancient stuff. Are you
sure you want to do that? It’s probably best that you seek professional advice. SSL 2

Mitigate Known Problems 11

 cannot be used securely—and it’s worse than no encryption because this protocol
version can be used to exploit secure servers (via DROWN). Nobody cares about TLS
1.1.
Weak Diffie-Hellman key exchange
There are some old clients (e.g., Java before version 8) that can’t use the DH key ex-
change at 2,048 bits, which is the recommended strength today. You may consider
dropping the strength to 1,024 bits to accommodate these clients. If you do, you
should generate a unique set of DH parameters on each server. You must not use any
of the predefined well-known groups because they can be exploited via a precompu-
tation attack. Anything below 1,024 bits is very easy to exploit.
You need to be aware that if you reduce the strength of the DH key exchange, it will
affect both modern and legacy clients. This is one aspect of TLS configuration that
cannot be negotiated on a per connection basis. The best approach is to have separate
systems for modern and legacy customers. If you can’t do that, preferring the ECDHE
key exchange (as in my recommended configuration) will ensure that modern clients
all use ECDHE and never attempt DHE.
Weak cipher suites
Once upon a time, it was necessary to make compromises to support some very old
user agents—for example, Windows XP and Android. These are bad at cryptography
and don’t support either DHE or ECDHE key exchange, not even AES. To support
these platforms you’ll need to support the plain old RSA key exchange that doesn’t
provide forward security. For Windows XP, you’ll need to support 3DES as well. You
very likely don’t need that, but here are some last-resort suites to place at the end of
your prioritized list of suites if there is no other way:
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA

HTTP and Application Security

Although SSL and TLS were designed so that they can secure any connection-oriented pro-
tocol, the immediate need was to protect HTTP. To this day, web site encryption remains
the most common TLS use case. Over the years, the Web has evolved from a simple docu-
ment distribution system into a complex application delivery platform. This complexity cre-
ates additional attack vectors and requires more effort to secure.

Encrypt Everything
There is no longer any excuse not to encrypt everything by default. A long time ago there
was—maybe—but not any longer. The first barrier fell with the increase of CPU power,

12 Chapter 1: Configuration Guide

which removed encryption as a computational bottleneck. More recently, several things
happened to make encryption widely adopted. First, there was the rise of Let’s Encrypt,
which started to offer free certificates and automated issuance. Second, browsers started to
mark plaintext content as insecure and search engines started to favor encrypted content.
Mixed content is the name we use to refer to web pages that are themselves encrypted but
rely on resources that are not. For example, an HTML page could be fetching audio or visual
files without encryption. The original excuse—that heavy content can’t be delivered encrypt-
ed—no longer applies, and today we need to deal with the legacy. Browsers have been re-
stricting mixed content for a while. The long-term direction is not only that all content
within a page must be encrypted, but also that the related actions (e.g., downloads) must be
as well.

Secure Cookies
In HTTP, cookies are a weak link and need additional attention. You could have a web site
that is 100% encrypted and yet remains insecure because of how its cookies are configured.
Browsers have been working hard to eliminate this problem, but they’ll need your help.
Mark cookies secure
Depending on the user agent, cookies may by default span both HTTP and HTTPS
contexts, which is why they need to be explicitly marked as secure to disable trans-
mission over insecure channels.
Mark cookies as HttpOnly
If a web site uses cookies that need not be accessed from the browser itself, they
should be marked as HttpOnly. This is a defense-in-depth technique that aims to
minimize the attack surface.
Use cookie name prefixes
Cookie prefixes are a new security measure that is now supported by browsers and
being added to the main cookie specification (RFC 6265bis). Cookies with names
that start with prefixes __Host- and __Secure- are given special powers that address a
variety of problems that existed for years. All cookies should be transitioned to use
these prefixes.
For best results, consider adding cryptographic integrity validation or even encryption to
your cookies. These techniques are useful with cookies that include application data. En-
cryption can help if the data inadvertently includes something that the user doesn’t already
know. Integrity validation will prevent tampering. With these kinds of cookies, it’s also a
good practice to bond the cookies to the context in which they were issued—for example, to
the user account to which they were issued.

Secure Cookies 13
Use Strict Transport Security
For proper security of the transport layer, you must indicate your preference for encrypted
content. HTTP Strict Transport Security (HSTS) is a standard that allows web sites to request
strict handling of encryption. Web sites signal their policies via an HTTP response header
for enforcement in compliant browsers. Once HSTS is deployed, compliant browsers will
switch to always using TLS when communicating with the web site. This addresses a num-
ber of issues that are otherwise difficult to enforce: (1) users who have plaintext bookmarks
and follow plaintext links, (2) insecure cookies, (3) HTTPS stripping attacks, and (4) mixed-
content issues within the same site.
In addition, and perhaps more importantly, HSTS fixes handling of invalid certificates.
Without HSTS, when browsers encounter invalid certificates, they allow their users to pro-
ceed to the site. Many users can’t differentiate between attacks and configuration issues and
decide to proceed, which makes them susceptible to active network attacks. With HSTS,
certificate validation failures are final and can’t be bypassed. That brings TLS back to how it
should have been implemented in the first place.
All web sites should deploy HSTS to fix legacy browser issues in how encryption is handled.
In fact, deploying HSTS is probably the single most important improvement you can make.
The following configuration enables HSTS on the current domain and all subdomains, with
a policy duration of one full year:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

For best results, consider adding your properties to the HSTS preload list. With that,
browsers and other clients can ship with a full list of encryption-properties, which means
that even first access to those sites can enforce encryption.

Warning
Unless you have full control over your infrastructure, it’s best to deploy HSTS in-
crementally, starting with a short policy duration (e.g., 300 seconds) and no
preloading. The fact that HSTS has a memory effect, combined with its potential
effect on subdomains, can lead to problems in complex environments. With incre-
mental deployments, problems are discovered while they’re still easy to fix. Request
preloading as the last deployment step, and after you activate sufficiently long poli-
cy duration.

HSTS is not the only technology that can help with enforcing encryption. Although much
more recent and with a lot of catching up to do, there are also the HTTPS DNS resource
records, which build on the DNS infrastructure to carry various metadata, including signal-
ing of support for encryption.

14 Chapter 1: Configuration Guide

In the SMTP space, there is MTA Strict Transport Security (MTA-STS), which enforces en-
cryption for transmission of email messages.

Deploy Content Security Policy

Content Security Policy (CSP) is a mechanism that enables web sites to control how re-
sources embedded in HTML pages are retrieved. As with HSTS, web sites signal their poli-
cies via an HTTP response header for enforcement in compliant browsers. Although CSP
was originally primarily designed as a way of combating XSS, it has an important applica-
tion for web site encryption; that is, it can be used to prevent third-party mixed content by
rejecting plaintext links that might be present in the page via the following command:
Content-Security-Policy: upgrade-insecure-requests

Disable Caching
Encryption at the network level prevents both passive and active network attacks, but TLS
doesn’t actually provide full end-to-end encryption. Both sides involved in the communica-
tion have access to the plaintext. Caching is commonly used with HTTP to improve perfor-
mance, so, for example, browsers may choose to store plaintext data in persistent storage.
Intermediate proxy services (e.g., content delivery networks) may choose to not only cache
sensitive data, but even share it with other users in some situations when incorrect configu-
ration is involved.
With the increase of cloud-based application delivery platforms and content delivery net-
works, it’s never been more important to very carefully mark all sensitive content as private.
The most secure option is to indicate that the content is private and that it must not be
cached:
Cache-Control: private, no-store

With this setting, neither intermediate devices nor browsers will be allowed to cache the
served content.

Be Aware of Issues with HTTP Compression

In 2012, the CRIME attack showed how data compression can be used to compromise net-
work encryption, and TLS in particular. This discovery eventually led to the removal of
compression from TLS. The following year, TIME and BREACH attack variations focused
on retrieving secrets from compressed HTTP response content. Unlike TLS compression,
HTTP compression has a huge performance and financial impact and the world decided to
leave it on—and to leave the security issues to linger.

Deploy Content Security Policy 15

TIME and BREACH attacks can target any sensitive data embedded in a HTML page,
which is why there isn’t a generic mitigation technique. In practice, most attacks would tar-
get CSRF tokens, which would give attackers the ability to carry out some activity on a web
site under the identity of the attacked user. For best security, ensure that CSRF tokens are
masked. In addition, web sites should generally be looking at adopting same-site cookies,
another recent security measure designed to improve cookie security, this time against
CSRF attacks.

Understand and Acknowledge Third-Party Trust

When everything else is properly configured and secured, we still can’t escape the fact that
many web sites rely on services provided by third parties. It could be that some JavaScript
libraries are hosted on a content delivery network or that ads are supplied by an ad delivery
network or that there are genuine services (e.g., chat widgets) supplied by others.
These third parties are effectively a backdoor that can be used to break your web site. The
bigger the service, the more attractive it is. For example, Google Analytics is known to pro-
vide its service to half the Internet; what if its code is compromised?
This is not an easy problem to solve. Although it would be ideal to self-host all resources
and have full control over everything, in practice that’s not quite possible because we don’t
have infinite budgets to do everything ourselves. What we should do, however, is evaluate
every third-party dependency from a security perspective and ask ourselves if keeping it is
worth the risk.
A technology called Subresource Integrity (SRI) can be used to secure resources that are
hosted by third parties and that don’t change. SRI works by embedding cryptographic hash-
es of included references, which browsers check every time the resource is retrieved.

Performance
Everybody worries about security, but they worry about performance even more. What use
is a secure service that people can’t or don’t want to use? Properly configured, TLS is plenty
fast. With little effort, the performance will be good enough. In some cases, it’s even possible
to deploy TLS with virtually no performance overhead. In this section, we’ll look at how you
can achieve best-in-class performance with some additional effort.

Don’t Use Too Much Security

We all like security, but it’s possible to have too much of it. If you go overboard and choose
cryptographic primitives that are too strong, your security won’t be better in any meaning-
ful way, but your services will nevertheless be slower, and sometimes significantly so. Most

16 Chapter 1: Configuration Guide

sites should aim to use elements that provide 128 bits of security. We make an exception for
DHE, which, at 2,048 bits, provides 112 bits of security. That’s close enough. You will virtu-
ally always use ECDHE anyway, which provides a full 128 bits of security.
The next step up is to use primitives that offer 256 bits of security. This is something you
might decide to do if you think quantum computing is a realistic threat, either today or in
the attack window relevant to you.

Enable Session Resumption

In TLS terminology, when a client and server have a successful handshake, they establish a
session. Handshakes involve a fair amount of computation, which is why cryptographic pro-
tocols focused on performance also incorporate so-called session caching that makes it pos-
sible to continue to use the results of one handshake over a period of time, typically for up
to a day. This is called session caching or session resumption.
Session resumption is an essential performance optimization that ensures smooth opera-
tion, even for web sites that don’t need to scale. Servers that don’t use it or don’t use it well
are going to perform significantly slower.

Optimize Connection Management

In the early days, slow cryptographic operations were the main bottleneck introduced by
encryption. Since then, CPU speed has improved greatly, so much so that most sites don’t
worry about its overhead. The main overhead of TLS now lies with the increased latency of
the handshake. The best way to improve TLS performance is to find ways to avoid hand-
shakes.
Keep connections open
The best approach to avoiding TLS handshakes is to keep existing connections open
for an extended period of time and reuse them for subsequent user requests. In
HTTP, this feature is known as keep-alives, and using it is a simple matter of web
server reconfiguration.
Use TLS 1.3
The complete redesign of TLS in version 1.3 to improve security was also a good op-
portunity to improve its performance. As a result, this protocol version reduces full
handshake latency by half, compared to the standard handshake in earlier protocol
revisions. TLS 1.3 also introduces a special 0-RTT (zero round-trip time) mode, in
which TLS adds no additional latency over TCP. Your servers will fly with this mode
enabled, but with the caveat that using it opens you up to replay attacks. Because of
this, this mode is not appropriate for use with all applications.

Enable Session Resumption 17

 Use modern HTTP protocols
There was a very fast pace of HTTP protocol evolution recently. After HTTP/1.1,
there was a long period of no activity, but then we got HTTP/2 and soon thereafter
HTTP/3. These two releases didn’t really change HTTP itself but focused on connec-
tion management and the underlying transport mechanism, including encryption via
QUIC.
Use content delivery networks
Content delivery networks (CDNs) can be very effective at improving network perfor-
mance, provided they are designed to reduce the network latency of new connections
to origin servers. Normally, when you open a connection to a remote server, you need
to exchange some packets with it for the handshake to complete. At best, you need to
send your handshake request and receive the server’s response before you can start
sending application data. The further the server, the worse the latency. CDNs, by defi-
nition, are going to be close to you, which means that the latency between you and
them is going to be small. CDNs that keep connections to origin servers open won’t
have to open new connections all the time, leading to potentially substantial perfor-
mance improvements.

Enable Caching of Nonsensitive Content

An earlier section in this guide recommended that you disable HTTP caching by default.
Although that’s the most secure option, not all properties require the same level of security.
HTTPS is commonly used for all web sites today, even when the content on them is not sen-
sitive. In that case, you want to selectively enable caching in order to improve performance.
The first step might be to enable caching at the browser level by indicating that the content
is private:
Cache-Control: private

If you have a content delivery network in place and want to utilize its caching abilities, indi-
cate that the content is public:
Cache-Control: public

In both situations, you can use other HTTP caching configuration options to control how
the caching is to be done.

Use Fast Cryptographic Primitives

Measured server-side, the overhead of cryptography tends to be very low and there aren’t
many opportunities for performance improvements. In fact, my recommended configura-

18 Chapter 1: Configuration Guide

tion is also the fastest as it prefers ECDSA, ECDHE, and AES with reasonable key sizes.
These days, to deploy fast TLS, you generally (1) deploy with ECDSA keys and (2) ensure
that your servers support hardware-accelerated TLS.
However, things change somewhat if we look at the performance from the client perspec-
tive. Recently there’s been an explosion in the adoption of mobile devices, which use differ-
ent processors and have different performance characteristics. What’s good for your servers
may not be good for mobile phones. So which do you want to optimize?
In practice, some organizations choose to take a performance hit on their servers in order to
provide a better end user experience. In practice, this means that they choose to negotiate
ChaCha20 suites with mobile devices because they are not only several times faster, but also
consume less battery. But how do we know which clients are mobile devices?
The trick is to use something called an equal preference cipher suites configuration. Normally,
we want our servers to select the best possible cipher suite, so naturally that would be some-
thing with AES-GCM. But with mobile devices we want ChaCha20. BoringSSL was the first
to introduce a feature in which the client’s list of suites is analyzed to determine if it prefers
ChaCha20 over AES. Only if it did would the server select a ChaCha20 suite over an AES-
GCM one. This feature is now also available in OpenSSL.

Validate and Monitor

Configuring TLS, especially for use on web sites, has become increasingly complex in recent
years. There are so many options to choose that you’re virtually guaranteed to get something
wrong when you first try. Moreover, things change and break—sometimes accidentally,
sometimes through software upgrades. For that reason, we recommend that you find a reli-
able configuration monitoring tool that you can trust. Use it periodically and continuously
to ensure that you stay secure.
Modern browsers support user agent reporting, which can give you real-time insight into
problems that your users are experiencing. CSP is one such technology that supports re-
porting, and even a report-only mode (no policy enforcement) for testing purposes. A more
recent technology, called Network Error Logging (NEL), provides reporting for a wider range
of network problems, including TLS and PKI.1

1 There is also the Expect-CT HTTP response header, which was designed to support early opt-in into CT before this technology became de facto

required. With Expect-CT reporting, it’s possible to get a full certificate chain that’s not CT compliant. Although this feature is very useful, it is
most likely that Expect-CT will be deprecated, now that pre-CT public certificates have all expired.

Validate and Monitor 19