IT Security Guidelines for

Transport Layer Security (TLS)

National Cyber Security Centre
The National Cyber Security Centre (NCSC), in collaboration with The following organizations and individuals have provided
the business community, government bodies and academics, is valuable contributions:
working to increase the ability of Dutch society to defend itself in - Autoriteit Persoonsgegevens
the digital domain. - Belastingdienst
- Centric
The NCSC supports the central government and organisations in - Dienst Publiek en Communicatie
the critical infrastructure sectors by providing them with expertise - Forum Standaardisatie
and advice, incident response and with actions to strengthen crisis - IBD
management. In addition, the NCSC provides information and - KPN
advice to citizens, the government and the business community - NLnet Labs
relating to awareness and prevention. The NCSC thus constitutes - Northwave
the central reporting and information point for IT threats and - Platform Internetstandaarden
security incidents. - RDW
- SURFnet
These IT Security Guidelines for Transport Layer Security were first - de Volksbank
published by the NCSC in 2014. This update (v2.1) was published in - Z-CERT
2021. See the appendix Changes to these guidelines for more details.
- Daniel Kahn Gillmor, ACLU
This publication was produced in collaboration with the following - Tanja Lange, Eindhoven University of Technology
partners: - Kenny Paterson, ETH Zurich
- the national communication security agency (NBV), part of the - Rich Salz, Akamai Technologies
general intelligence and security service (AIVD) - Nick Sullivan, Cloudflare
IT Security Guidelines for
Transport Layer Security (TLS)
4 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Contents

Introduction5 4 Versions, algorithms and options 15

Purpose5 Versions15
Use for procurement 5 Cryptographic algorithms 15
Level of security 5 Algorithms for certificate verification 16
Key message 6 Algorithms for key exchange 16
Outline6 Algorithms for bulk encryption 17
References6 Key sizes and choice of groups 18
RSA key size 18
1 What is Transport Layer Security? 7 Supported elliptic curves 18
How TLS works 7 Supported finite field groups 18
Software libraries 8 Options19
The importance of random numbers 8 Compression19
Renegotiation19
2 Usage guidance 9 0-RTT20
Scenario 1: Control over both client and server 9 OCSP stapling 20
Scenario 2: Only control over the server 10
Points of particular interest 11 Appendix A –Further considerations 21
Diverging from these usage guidelines 11 Forward secrecy 21
Session tickets 21
3 Guidelines 12 Random number generators 21
Versions12 Certificate management 22
Algorithm selections 12 Where does a TLS connection terminate? 22
Certificates13 Post-quantum security 23
Key exchange 13 Authenticating clients with certificates 23
Elliptic curves 13 Certificate pinning and DANE 23
Finite fields 14
Other options 14 Appendix B – Changes to these guidelines 24
Compression14 Validity24
Renegotiation14 Critical changes 24
0-RTT14 New versions 24
Scheduling removal of Phase out configurations14
Appendix C – List of cipher suites 25

Appendix D – Glossary 26

References29
5 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Introduction

These guidelines are intended as advice during procurement, To aid in the choice of a configuration, the settings for the options
set-up or review of configurations of the Transport Layer Security available in TLS are divided in four security levels.
protocol (TLS) on servers. TLS is the most popular protocol to - A setting that is Insufficient should not be chosen. TLS
secure connections on the Internet. configurations that contain these settings are not secure.
- A Phase out setting is known to be fragile with respect to
evolving attack techniques and merely provides a slim security
Purpose margin. This places them at risk of becoming Insufficient in the
near future. For some applications, Phase out settings are (still)
These guidelines do not contain step-by-step instructions for the needed to support very old clients. The use of these settings
configuration of TLS.1 Nevertheless, they are technical in nature. should be subject to written deprecation conditions that
This publication helps an organisation choose between all possible schedule their removal.
configurations of TLS to arrive at a secure configuration. An - If a setting is Sufficient, it ‘does the job’ for the time being. It is
administrator or supplier then applies this configuration. possible to use such a setting in a secure TLS configuration.
Many Sufficient settings are required for compatibility with
older client systems.
Use for procurement - The most secure and future-proof settings are Good. If you have
the freedom to choose which settings you support, then only
Organisations that procure IT systems can refer to this publication use Good settings.
when stating their requirements. A supplier is thus asked to supply
and maintain a secure TLS configuration by conforming to the New or improved attack techniques periodically appear for TLS.
guidelines in this publication. These attack techniques usually concern Phase out or Sufficient
settings. A setting rendered insecure by an attack technique will
lose its status as Phase out, Sufficient or Good. If that happens an
Level of security addendum to these guidelines will be published. For further
details, see the appendix Changes to the guidelines.
Deciding on the right TLS configuration is ultimately each
organisation’s prerogative. It is a complex job. Each option requires Good settings are likely to be more future-proof than Sufficient
a choice between the available alternatives, where often many settings. Even so, there are no guarantees. Moreover, no single TLS
exist. Security plays a role here, but so does compatibility with configuration remains secure forever. Even TLS configurations
software of customers or end users. The guidelines in this consisting only of Good settings will need updates at some point.
publication help navigate this effort. This is the case when Good settings become Insufficient.
The words ‘insufficient’, ‘phase out’, ‘sufficient’ and ‘good’ have a
meaning in regular use. To distinguish these uses, they are
displayed in a different font throughout this publication when
referring to a security level.

1 The book ‘Bulletproof SSL and TLS’ by Ivan Ristic (ISBN 978-
1907117046) offers step-by-step instructions on the configuration of various
software for the secure use of TLS, in addition to extensive background
information. Mozilla offers configuration examples for popular web server
software on its wiki https://wiki.mozilla.org/Security/Server_Side_TLS. The
website https://bettercrypto.org/ also offers step-by-step instructions. Note
that these resources may not yet be up to date with the introduction of TLS
1.3 and that the advice in these publications differs slightly from the advice in
this document.
6 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Key message These guidelines can be read in three ways:

- If you are designing a TLS configuration yourself, then read the
The secure configuration of TLS is important to secure network chapter What is Transport Layer Security?, followed by the chapter
connections. TLS has secure and less secure settings. Legacy Usage guidance. The chapter Usage guidance will refer you to the
software does not always support the most secure settings. Use relevant parts of the chapter Versions, algorithms and options.
Good settings when possible and complement these with - Do you want to know how certain settings for TLS options
Sufficient settings to support legacy software. Do you need to influence its security? Then refer to the chapter Versions,
support a lot of legacy software? Then use a broad palette of algorithms and options.
Sufficient settings and complement it with Good settings where - Are you assessing a TLS configuration? Then read the chapter
possible. Use Phase out settings only whilst you have a further What is Transport Layer Security?, followed by the chapter Guidelines.
need for client compatibility and set clear criteria for their The chapter Guidelines will refer you to the relevant parts of the
deprecation. Do not use Insufficient settings. chapter Versions, algorithms and options.

Outline References
The core of these guidelines consists of the chapters Usage guidance, This publication makes use of multiple styles of references:
Guidelines and Versions, algorithms and options. The chapter Usage - Guidelines are numbered, say B2-1, and are found in the chapter
guidance is aimed at people that need to create their own secure TLS Guidelines.
configuration. It offers guidance to arrive at a secure configura- - Technical terms are not always introduced upon first use. If a
tion. The chapter Guidelines is meant for people who judge TLS term is marked in this way, then it can be found in the Glossary at
configurations, such as auditors. This may include configurations the back.
on paper or in practice. The chapter Versions, algorithms and options - To supply background information, footnotes2 are used.
lists relevant TLS options. It describes secure settings for every - The support for the advice provided is based on the References
option listed. Other chapters regularly refer to the chapter Versions, that can be found in the back. If a particular reference supports
algorithms and options for details. an advice, it is shown in the following manner: (1)

2 In this manner.
7 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

1 What is Transport Layer

Security?

Transport Layer Security (TLS) is a protocol for the establishment In every example, use of TLS ensures that the data sent cannot be
and use of a cryptographically secured connection between two seen or modified by others in transit. Because sensitivity is
computer systems, a client and a server. After establishing a secure user-dependent, encrypted communication (and TLS) have
connection with the TLS protocol, applications can use the become the norm, rather than the exception in many contexts.
connection to exchange data between the client and the server.
TLS is applied in a large number of contexts. Well known examples TLS only protects the contents of the communication. Information
include web traffic (https), e-mail traffic (IMAP and SMTP after about the data transport is not protected. In this aspect, TLS differs
STARTTLS) and certain types of virtual private networks (VPN). from IPsec. TLS works on the transport layer. IPsec works on the
internet layer.7

Why TLS?
There are currently seven different versions of TLS. Three carry its
TLS protects the communication between client and server. old name: Secure Sockets Layer (SSL) 1.0, 2.0 and 3.0. These were
The protection of communication is important when sensitive developed by Netscape. Then came TLS 1.0, 1.1, 1.2 and 1.3. These
information is sent over a connection. Information can be were standardized by the Internet Engineering Task Force (IETF).
sensitive due to confidentiality (say login credentials) and due to The IETF maintains TLS as an open standard. The most recent
integrity (say a financial transaction). version of TLS is 1.3.8
In some cases, the use of encrypted connections is obligatory.
This obligation can flow from an organization’s policy, but also A client or server can support multiple versions of TLS.
from law or regulation: The individual versions are not compatible. Every version has its
• The Dutch Standards Forum’s “comply or explain” regime own options, for example in bulk encryption, authentication and
requires use of TLS for communication between parts of the key exchange.
Dutch government, such as the secure exchange of e-mail.3 Use
of HTTPS will become mandatory for all government websites.4
• The PCI Data Security Standard (PCI DSS) is a payment industry How TLS works
policy that requires the use of encrypted transmission of
cardholder data over open, public networks.5 A connection between a client and server secured by TLS is called a
• The Dutch Data Protection Authority (Autoriteit Persoons­ TLS session. A TLS session consists of two phases: the handshake
gegevens) requires the use of HTTPS on websites that collect phase and the application phase. During the handshake, the client
personal data.6 This requirement flows from the General Data and server agree on the way the TLS session is established. The
Protection Regulation. following are examples of matters that need to be agreed upon
during the handshake:
3 (Dutch) https://www.forumstandaardisatie.nl/standaard/tls. - What version of TLS will be used?
4 (Dutch) https://www.rijksoverheid.nl/ministeries/ - What key will be used to exchange further data and how will it
ministerie-van-binnenlandse-zaken-en-koninkrijksrelaties/
documenten/kamerstukken/2018/10/16/ 7 The transport layer and the internet layer are part of the internet
kamerbrief-over-verhogen-informatieveiligheid-bij-de-overheid protocol suite, a model to describe network traffic. This model is
5 PCI-DSS v3.2.1, Req. 4, see https://www.pcisecuritystandards.org described in RFC 1122, available at https://datatracker.ietf.org/doc/
6 (Dutch) https://autoriteitpersoonsgegevens.nl/nl/onderwerpen/ rfc1122/.
beveiliging/beveiliging-van-persoonsgegevens#moet-ik-altijd-https- 8 The specification of TLS 1.3 is documented in RFC 8446, available at
gebruiken-voor-mijn-website-6069 https://datatracker.ietf.org/doc/rfc8446/.
8 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

be chosen (key exchange)? Ask the supplier of your chosen TLS library (or the vendor that
- Which certificate will the server use to prove its identity to the embeds it) about the following topics to get a rough understanding
client? of its dependability. Does your chosen TLS software library:
- Will the client present a certificate? If so, which? - document how to report security vulnerabilities?
- What cipher suite will be used to encrypt data during the - have developers that have access to enough resources to provide
application phase? (security) support?
- have a good track record of responding to past attacks on TLS or
The handshake is started by the client. During the handshake, the vulnerabilities in its implementation in the library?
client and server negotiate four cryptographic algorithms, one - make their security-updates known to their users and distinct
algorithm for key exchange, one algorithm for digital signatures, from feature updates?
one algorithm for bulk encryption and an algorithm for hashing. - get audited or independently reviewed?
In these guidelines, this set of four algorithms is called an - use constant time implementations to harden against attacks
algorithm selection. 9 Then, the client verifies the authenticity of based on timing side channels?
the certificate that the server provides. If the client offers a
certificate to the server, its authenticity is verified by the server.10 The NCSC advises to make conscious choices on the use of TLS
libraries:
After the handshake phase completes, the application phase starts. - Always use the most recent version of your chosen TLS library.
During the application phase, the TLS session is available as a This gives its creators the most time to fix vulnerabilities.
secure tunnel for data transfer. Applications can use this tunnel to - Choose only settings that are necessary to meet business
send their traffic between client and server. Applications do not requirements. This way, bugs in non-necessary functionality
have to concern themselves with the inner working of this tunnel: will not lead to system vulnerabilities. The chapter Usage
they can trust it as an abstract communications channel that guidance helps with this selection.
guarantees confidentiality and integrity of information.

The importance of random numbers

Software libraries
Random numbers play a crucial role in many applications of
TLS is used in many different software applications. Programming cryptography, including TLS. TLS uses random numbers in multiple
all functionality in TLS from scratch is a lot of work and requires places in the protocol.
specialist knowledge. That is why most software does not contain
its own code for TLS. Instead, they use a TLS software library. The quality of the random numbers used is critical to the security
of TLS. Choosing the right settings for TLS is important, but no
There are different TLS software libraries available. Some are free single setting can take away the risks introduced by using random
software; others are available as a proprietary product. They can be numbers of low quality.
included in operating systems or delivered separately. Well known
TLS libraries include OpenSSL11, SChannel12, NSS13 and mbed TLS14. Every operating system and every TLS library contains methods to
These guidelines do not judge the security of specific TLS libraries. generate random numbers. In addition, hardware is available for
All software contains bugs, including TLS libraries. Bugs can lead to the generation of random numbers. These hardware modules
vulnerabilities. Every library has its advantages and disadvantages. produce random numbers faster and of higher quality than
Not every setting for TLS is available in each library. software-only methods do.

You can find more background and advice on methods to generate

random numbers in the section Random number generators in the
appendix Further considerations.

9 See the callout Changed meaning of cipher suite in TLS 1.3 in the chapter
Guidelines for the reason behind this naming convention.
10 Note that TLS versions prior to TLS 1.3 do not fully encrypt the
information exchanged during the handshake. This affects client
certificates, which are sent unencrypted.
11 https://www.openssl.org/
12 https://docs.microsoft.com/en-us/windows/desktop/secauthn/
secure-channel
13 https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
14 https://tls.mbed.org/
9 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

2 Usage guidance

The guidelines in this publication are aimed at the security of a Scenario 1:

TLS configuration. In practice, security is not the only concern
when choosing a configuration. The TLS configuration of the server Control over both client and server
should also be compatible with the TLS configurations of all clients
that need to connect to the server. The configurations of client and In some situations, the party that has control over the configura-
server need to match in certain aspects. tion of the server also has control over the configuration of the
client. An example is a web server serving an internal web
For some choices, different selections for client and server do not application. This web server is only available to the same
exclude one another. This includes supported versions, algorithm organisation’s clients. The NCSC advises to use Good settings in
selections and groups. To allow a client and server to communi- this scenario: this is the most secure and most future-proof
cate, each of these options needs to have one choice that both configuration. In the chapter Versions, algorithms and options you can
client and server support. For example, if the client supports TLS find which settings are Good.
1.0, TLS 1.1 and TLS 1.2 it can communicate with a server that
supports TLS 1.0 and TLS 1.1, but not with a server that only Step by step
supports TLS 1.3. The same principle applies to algorithm selec- 1. Make an inventory of the available TLS options that are available
tions and supported groups. on the server.
2. Inventory the different clients that will make connections to the
Other choices determine how long the cryptographic key or server.
parameter is. This includes RSA keys and ECDSA keys. To allow a 3. Inventory for each type of client the set of settings that are
client and server to communicate, both client and server need to supported.15
support the chosen length of the key or parameter. Older software 4. Choose Good settings for the following options:
does not always support keys or parameters of sufficient length and a. TLS version for the server. Ensure that every client supports a
newer software sometimes prevents the use of keys or parameters version that is also supported by the server.
of insufficient length. b. Algorithm selections for the server. Ensure that every client
supports an algorithm selection that is also supported by the
Finally, there are options: configurations that can only be turned server.
‘on’ or ‘off’. For example, a server does or does not support TLS c. Key lengths for the server. Ensure that every client supports
compression. Configuring a server with the options that are the chosen length.
included in this publication is not known to cause compatibility d. Supported elliptic curves for the server. Ensure that every
problems with clients. client supports an elliptic curve that is also supported by the
server. Finite field groups supported by the server, in case
TLS has a plethora of options beyond those discussed. We only older clients do not support elliptic curves. In that case,
discuss options that influence the security of TLS and that are ensure that every client supports a Sufficient finite field
sometimes not secure by default. group that is also supported by the server.
e. Other options for the server, unless there are strong reasons
to choose Sufficient settings. These reasons flow from the
client inventory created.

15 An overview of TLS configurations for different types of clients is

available from https://www.ssllabs.com/ssltest/clients.html.
10 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

5. Does the server lack support for a Good setting that clients Step by step
support? You have three options: 1. Make an inventory of the types of clients that (need to) make
a. Replace the clients by a type that does support Good settings connections to the server.17 This is a requirement that is usually
for this option. determined in consultation with the business owner.
b. Replace the server by a type that does support Good settings a. Make the trade-off visible: the value of compatibility versus
for this option. the risk and associated support cost of increasingly fragile
c. Choose a Sufficient setting for this option that is supported configurations.Make an inventory of the available TLS
by both clients and server. options that are available on the server.
6. Does the server lack support for a Good and Sufficient setting 2. Choose Good and Sufficient TLS-versions for the server.
that clients support? You have three options: 3. Choose Good and Sufficient algorithms for the server. Support
a. Replace the clients by a type that does support (other) Good a broad range of Sufficient algorithms. These are often required
or Sufficient settings for this option. for compatibility with older clients. Do not support more
b. Replace the server by a type that does support Good or Sufficient algorithms than required for compatibility.
Sufficient settings for this option. 4. Choose Sufficient lengths of keys. Choose Good lengths
c. Choose a Phase out setting for this option that is supported instead if you are sure that all clients support these.
by both clients and server. This option is least preferred, 5. Choose Good elliptic curves for the server. Do you have reasons
because it comes with additional risk and is the least to assume that not every client supports these? Then also
future-proof of all available configurations. choose Sufficient elliptic curves. Do not support more curves
7. Configure the server with the chosen configurations. The TLS than required for compatibility.
configuration is part of the software that uses the TLS connec- 6. Some old clients do not support elliptic curves. Do you need to
tion. For example, if you want to offer HTTPS then TLS is support these clients? Then select Sufficient finite field groups.
configured as part of the web server software. Do not support more finite field groups than necessary for
8. Test to establish that this configuration works for all types of compatibility.
clients. Do you run into any compatibility issues? Then go back 7. Configure the server with the chosen configurations. The
to step 5. TLS configuration is part of the software that uses the TLS
9. Document the selected settings. Spend time on at least the connection. For example, if you want to offer HTTPS then
following: TLS is configured as part of the web server software.
a. Choose and document conditions for scheduled removal of 8. Think about the software that clients will use to connect.
any Phase out settings that have been chosen. See Scheduling Test whether clients using this software can connect.
removal of phase out configurations in the chapter Guidelines for 9. Are you having compatibility problems?18 Track down which
examples of clear conditions. options cause these problems.
b. Document the reasons for choosing Sufficient instead of a. Usually these problems can be solved by exchanging or
Good settings. supplementing Good settings with Sufficient settings.
b. If the inventory created in steps 1 and 9 includes very old
client software, you may need to temporarily include Phase
Scenario 2: out settings in your configuration. Phase out settingss are
known to be fragile with respect to evolving attack
Only control over the server techniques and merely provide a slim security margin.
Do not support more Phase out algorithms than required for
In other situations, the entity with control over the configuration compatibility.
of the server does not control the configuration of (all) clients that 11. Choose and document clear criteria for the scheduled removal
connect to the server.16 An example is a web server serving a public of any Phase out settings that have been chosen. See Scheduling
website. The NCSC advises to use Good settings and to complement removal of phase out configurations in the chapter Guidelines for
these with Sufficient settings in this scenario. In some deploy- examples of clear conditions. If removal impacts the require-
ments, it may be necessary to include Phase out settings while ment defined in step 1, this will usually involve consultation
clients transition away from these less secure configurations. In with the business owner.
the chapter Versions, algorithms and options you can find which
settings that are respectively Good, Sufficient and Phase out.

17 Ideally by using TLS connection statistics gathered on the server, or on a

similar service.
18 Does your organization make use of TLS interception, either locally on
the client or on the network? This may be the source of your
compatibility problem. The factsheet “TLS Interception” treats
16 This heading can also be read as “Only control over the client”, though considerations and preconditions for the deployment of TLS
clients are not the focus of these guidelines. An example is an e-mail interception. (https://english.ncsc.nl/publications/factsheets/2019/
service that acts as a TLS client when sending e-mail. juni/01/factsheet-tls-interception)
11 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Points of particular interest

- The guidelines in this publication influence the selection of a
supplier for certificates: not every certificate supplier can supply
every type of certificate. So discuss your TLS configuration with
the administrators of certificates and public key infrastructures
(PKIs) within your organisation.
- Checking TLS configurations can be part of vulnerability
management, penetration tests and the regular audit cycle
within your organisation. Several tools and websites exist that
enable you to perform similar checks yourself.19 You can
compare the results of these checks to the guidelines. This way,
you are ahead of any findings during a penetration test or audit.
- Operating systems usually contain more than one TLS software
libary. Make sure you know which software library is used by the
server software and ensure it remains up to date.

Diverging from these usage

guidelines
The NCSC advises to set up TLS configurations based on these
guidelines at all times. Still, this may prove unattainable in
exceptional circumstances. Keep the following in mind in such
situations:
- Perform risk analysis when diverging from the guidelines.
Diverging will have a negative impact on security. Why is this
acceptable? How did you arrive at that conclusion? What
additional measures will you take to mitigate the resulting
risks? Document the divergences and results of these
considerations.
- Something is better than nothing. Even a connection that
is protected by an Insufficient TLS configuration can be
impenetrable to some attackers. Inability to fully meet the
guidelines can never be a reason to disable TLS in its entirety.
- Assessing a TLS configuration requires extensive knowledge.
If you are diverging from this usage guidance, then discuss your
TLS configuration and the resulting risks with a domain expert.

19 Examples of such tools are testssl.sh (https://testssl.sh/) and sslyze

(https://github.com/nabla-c0d3/sslyze). The website Internet.nl allows
online testing against the guidelines in this publication for web and
e-mail servers (https://www.internet.nl/). The website Qualys SSL labs
allows for a similar online check for web servers (https://www.ssllabs.
com/ssltest/).
12 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

3 Guidelines

In the guidelines, repeated references are made to configurations Examples of these algorithms include:
that are Good, Sufficient or Phase out. All configurations refer- - Certificate verification: RSA, ECDSA, etc.
enced can be found in the chapter Versions, Algorithms and Options. - Key exchange: ECDHE, DHE, RSA, etc.
- Bulk encryption: AES-GCM, ChaCha20-Poly1305, etc.
- Hashing: SHA-1, SHA-256, etc.
Versions
Changed meaning of cipher suite in TLS 1.3
Recent versions of TLS are more secure than older versions. The
older versions of TLS contain vulnerabilities that cannot be The first version of these guidelines used the term cipher suite
repaired. These must therefore be avoided. A TLS configuration can instead of algorithm selection. We changed our use of terminol-
support more than one version. ogy to stay in step with a change in TLS 1.3.

Number Guideline A cipher suite up until TLS 1.2 included the algorithms for key
exchange and digital signatures. Most of the resulting hundreds of
B1-1 All supported versions of TLS are Good, Sufficient or
combinations are listed in the protocol registry.
Phase out

See Chapter 4 – Versions, algorithms and options, Table 1 – Versions To avoid this naming explosion, cipher suites in TLS 1.3 only
contain the algorithms used for bulk encryption and hashing.

Algorithm selections Figure 1 shows the changed cipher suite notation in TLS 1.2 and
TLS 1.3.
For each connection, the client and server negotiate the use of four
cryptographic algorithms. One algorithm for key exchange, one
algorithm for digital signatures in certificate verification, one To set up a connection, TLS negotiates the use of an algorithm for
algorithm for bulk encryption and one algorithm for hashing. We each of these purposes. There are hundreds of valid combinations
will refer to a set of four selected cryptographic algorithms as an available. A TLS configuration can support multiple algorithm
algorithm selection. The pair of cryptographic algorithms for bulk selections.
encryption and hashing are known as a cipher suite and are used
for record protection.

Figure 1 – Cipher suite notation in TLS 1.2 and TLS 1.3. The colours indicate the different algorithms and their purpose.
In TLS 1.3, the cryptographic algorithms for key exchange and certificate verification are no longer considered part of the cipher suite.
13 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Number Guideline Number Guideline

B2-1 All supported algorithm selections contain a Good, B3-4 If the supplied certificate is not directly signed by a root CA,
Sufficient or Phase out algorithm for certificate verifica- the server offers intermediate CA certificates that
tion. authenticate the path between the root CA and the supplied
certificate.
See Chapter 4 – Versions, algorithms and options,
Table 2 – Algorithms for certificate verification.

B2-2 All supported algorithm selections contain a Good,

Sufficient or Phase out algorithm for key exchange. Key exchange
See Chapter 4 – Versions, algorithms and options,
The algorithm for key exchange specifies how a client and server
Table 4 – Algorithms for key exchange.
determine a key for encrypted communication. Ephemeral
B2-3 All supported algorithm selections contain a Good, Diffie-Hellman is a method to derive a temporary shared key
Sufficient or Phase out algorithm for bulk encryption. between parties. There are variants of Diffie-Hellman based on
See Chapter 4 – Versions, algorithms and options, finite fields (DHE) and elliptic curves (ECDHE). More information
Table 6 – Algorithms for bulk encryption. on the use of ephemeral keys can be found in the section Forward
Secrecy in the appendix Further considerations.
B2-4 All supported algorithm selections contain a Good,
These guidelines do not specify a minimum size for the secret
Sufficient or Phase out algorithm for hashing.
parameter used in ephemeral Diffie-Hellman. This is generally
See Chapter 4 – Versions, algorithms and options, Table 7 – Hash hard-coded in the TLS software library or derived from a chosen
functions for bulk encryption and the generation of random numbers. group, not a setting an administrator can configure.
B2-5 All supported algorithm selections are Good, or the
algorithm selections are chosen by the server using the Number Guideline
prescribed ordering. B4-1 If DHE is used for key exchange, the secret parameter is
See Chapter 4 – Versions, algorithms and options, section Prefer faster ephemeral, chosen uniformly at random20 and of
and safer algorithms. appropriate size for the chosen finite field.

B4-2 If ECDHE is used for key exchange, the secret parameter

is ephemeral, chosen uniformly at random20 and of
Certificates appro­priate size for the chosen group.

TLS allows the server to prove its identity using an X.509 certificate.
The client can only establish through a certificate that it communi-
cates with the server and not a third party intending to listen in or Elliptic curves
manipulate its communication. Acquiring and managing certifi-
cates is not part of these guidelines. See the section Management of Computations with elliptic curves are said to happen ‘on’ an elliptic
certificates in the appendix Further considerations for pointers. curve. The curve is the context for the computation. For secure
communication, the choice of a suitable curve is necessary. Not
Number Guideline every curve offers the same security.

B3-1 The server offers a certificate for authentication.

Number Guideline
B3-2 The signed fingerprint of the certificate has been created
B5-1 All elliptic curves used are Good, Sufficient or Phase out.
using a Good, Sufficient or Phase out algorithm for hashing
(see “Hash functions for certificate verification”). See Chapter 4 – Versions, algorithms and options,
Table 9 – Supported elliptic curves.
See Chapter 4 – Versions, algorithms and options,
Table 3 – Hash functions for certificate verification.
Note that B5-1 applies both to key exchange based on ECDHE and to
B3-3 If the server offers a certificate with an RSA key, the length
digital signatures using ECDSA and EdDSA.
of this key is Good or Sufficient.

See Chapter 4 – Versions, algorithms and options,

20 The NCSC advises against the use of variations on the TLS protocol that
Table 8 – RSA key size. invalidate the security analysis of TLS 1.3 and its forward secrecy
property by fixing a DH parameter in some way. At the time of writing
the ETSI “Enterprise Transport Security (ETS)” specification (ETSI TS 103
523-3), previously known as “eTLS”, is one such example. The NCSC
factsheet “TLS Interception” treats considerations and preconditions for
the deployment of TLS interception using TLS proxies.
14 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Finite fields Number Guideline

B9-1 The settings for 0-RTT are Good, Sufficient or Phase out.
Computations with finite fields are said to happen ‘in’ a finite field.
The finite field is the context for the computation. For secure See Chapter 4 – Versions, algorithms and options, Table 14 – 0-RTT.
computation, the choice of a suitable finite field is necessary.
Not every finite field offers the same security, interoperability or
efficiency. Scheduling removal of Phase out
Number Guideline
configurations
B6-1 All finite fields used are Good, Sufficient or Phase out.
Phase out settings are known to be fragile with respect to evolving
See Chapter 4 – Versions, algorithms and options, attack techniques. They provide a slim security margin relative to
Table 10 – Supported finite field groups. their Sufficient or Good counterparts. They are at a higher risk of
becoming Insufficient in the near future.
The use of Phase out settings should be subject to written
deprecation conditions.
Other options
Number Guideline
TLS has a plethora of options beyond those discussed. We only
B10-1 Any supported configuration that is Phase out has a
discuss options that influence the security of TLS and that are
documented condition that schedules its removal.
sometimes not secure by default.
B10-2 Any configuration that is Phase out is not used past the
Compression documented condition that schedules its removal.
The use of compression can give an attacker information about the
secret parts of encrypted communication. Because data is first There is value in removing Phase out configurations when no
compressed and then encrypted, the effect of compression can longer required, because removed configurations can no longer be
yield information on the data that is sent. attacked or be used to attack other parts of TLS. At the same time,
compatibility requirements for some applications may require
Number Guideline their support until client support improves.

B7-1 The settings for compression are Good, Sufficient or

The NCSC advises not to support Phase out settings indefinitely.21
Phase out.
Document what requires their use and include conditions that
See Chapter 4 – Versions, algorithms and options, allow for removal when met. Thus, removal is scheduled upon use.
Table 11 – Compression.
Choosing when to cease support is application specific. The web
ecosystem deprecates old TLS versions and configurations faster22
Renegotiation than the e-mail ecosystem.23 These guidelines are application
Older versions of TLS (prior to TLS 1.3) allow forcing a new agnostic and therefore only contain generic advice.
handshake. This is called renegotiation.
The following are examples of documented conditions. Phase out
Number Guideline configurations A, B and C will be removed:
- on <date>;
B8-1 The settings for renegotiation are Good, Sufficient or
- with the release of <web browser> version X in the stable release
Phase out.
channel;
See Chapter 4 – Versions, algorithms and options, Table 12 – Insecure - when the relative number of users drops below Y%;
renegotiation; and Table 13 – Client-initiated renegotiation. - when the absolute number of users drops below Z per month.

21 Supporting outdated (client) software is also problematic for reasons

0-RTT unrelated to TLS: it is more likely to contain known security
0-RTT is an option in TLS 1.3 that transports application data vulnerabilities that have been patched in later versions.
during the first handshake message. 0-RTT does not provide 22 For example: by summer 2020 all modern web browsers had disabled
protection against replay attacks at the TLS layer and is therefore support for Phase out configurations suchs as TLS 1.0, TLS 1.1 and DHE.
hard to use securely in an application agnostic environment. 23 For example: removing Phase out settings may cause your mail servers
to exchange unencrypted e-mail with mail servers outside your control.
Retain the Phase out settings and document appropriate conditions for
removal if your statistics show this to be the case.
15 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

4 Versions, algorithms and

options

This chapter treats TLS versions, algorithms, key size & choice of The first three domains are covered in their own section. Hashing is
groups and options. The security of a configuration depends on the used as building block and covered within the other domains.
selections in each of these categories.
Figure 2 summarizes algorithm selections and their security level
The numbers in parentheses refer to the references on the last page and shows the correspondence between algorithm selection and
of this document. cipher suite notation in TLS 1.2 and TLS 1.3. The security levels
apply to algorithm selections as follows.

Versions Good, Sufficient and Phase out

A Good algorithm selection is an algorithm selection that consists
Recent versions of TLS are more secure than older versions. The of Good choices for each of the domains. Good algorithms offer a
oldest three versions of TLS, SSL 1.0, SSL 2.0 and SSL 3.0 cannot be security equivalent of at least 128 bits. Good algorithms by
used securely. The most recent version of TLS, TLS 1.3 offers the definition meet the guidelines B2-1 up to B2-4. See the row labelled
best protection. Good in Figure 2 for examples of combinations that result in a
Good algorithm selection.
Version Status
A Sufficient algorithm selection is a selection that consists of
TLS 1.3 Good (3; 4)
Sufficient choices and possibly Good choices for each of the
TLS 1.2 Sufficient (3; 4) domains. Sufficient algorithms by definition meet the guidelines
TLS 1.1 Phase out (3; 4) B2-1 up to B2-4. See the row labelled Sufficient in Figure 2 for
examples of combinations that result in a Sufficient algorithm
TLS 1.0
selection (possibly combined with choices from the row Good).
SSL 3.0 Insufficient (3; 4) Both Good and Sufficient algorithm selections only contain key
exchange algorithms that provide forward secrecy.
SSL 2.0

SSL 1.0 A Phase out algorithm selection is a selection that consists of

Table 1 – Versions Phase out choices and possibly Good or Sufficient choices for each
of the domains. See the row labelled Phase out in Figure 2 for
examples of combinations that result in a Phase out algorithm
Cryptographic algorithms selection (possibly combined with choices from the rows Good or
Sufficient).
The security of a TLS connection depends on the algorithms that
are configured. The guidelines to determine algorithm selections Prefer faster and safer algorithms
consist of guidelines in four domains: The NCSC advises to configure the server to prefer Good over
1. Certificate verification Sufficient over Phase out algorithm selections. This prioritizes the
2. Key exchange fastest and safest algorithms. Choose your own ordering within the
3. Bulk encryption different security levels. This is chiefly a performance
4. Hashing consideration.
16 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Figure 2 – Cipher suite notation in TLS 1.2 and TLS 1.3. The table summarizes algorithm selections and their security level.
Not included in the (old) cipher suite notation are: versions; hash functions for certificate verification; hash functions for key exchange; key sizes & choice of groups; and options.
These can be found in their respective sections. For ordering, refer to the section Prefer faster and safer algorithms.

When the server only supports Good algorithm selections, it may Hash functions for certificate verification
honor the client's preference and does not need to enforce its own The digital signatures on certificates use hash functions. The
ordering. security of the chosen hash function is important for this purpose.

Algorithms for certificate verification Algorithm Status

The verification of certificates makes use of digital signatures.
SHA-512 Good (1; 3)
To guarantee the authenticity of a connection, a trustworthy
algorithm for certificate verification must be used. The algorithm SHA-384
that is used to sign a certificate is selected by its supplier. SHA-256

SHA-1 Insufficient (1; 3)

The certificate specifies the algorithm for digital signatures that is
used by its owner during the key exchange. It is possible to MD5
configure multiple certificates to support more than one Table 3 – Hash functions for certificate verification
algorithm.

Algorithm Status Algorithms for key exchange

A TLS connection starts with a key exchange to establish a session
ECDSA Good (2; 3)
key. Key exchange algorithms offering forward secrecy provide
RSA confidentiality of past communications in the event of secret key
DSS24 Insufficient compromise. Static key exchange algorithms use the public key
embedded in the certificate to transport an encrypted copy of the
EXPORT-variants session key. Key exchanges based on ECDHE and DHE provide
PSK forward secrecy. Key exchanges based on static RSA, ECDH and
DH keys in certificates do not.25
Anon

NULL
Table 2 – Algorithms for certificate verification

The algorithm EdDSA is Good, but not (yet) permitted for use by
suppliers of certificates (1) and therefore not added to the table.
25 Confidentiality under static RSA, ECDH and DH relies on keeping long
term keys secret. An attacker can steal this long term key in the future
24 The algorithm DSS has been uncommon for a long time. It is Insufficient and break confidentiality of past traffic. Under ECDHE and DHE, keys are
because rarely used code sees less testing and has a higher chance to kept for a very short term and are then destroyed, which leaves nothing
contain undiscovered vulnerabilities. to be stolen.
17 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

SHA2 support for signatures30 Status

Algorithm Status Yes (SHA-256, SHA-384 or SHA-512 supported) Good (3; 4)
ECDHE Good (3) No (SHA-256, SHA-384 or SHA-512 not supported) Phase out (3; 4)
DHE Sufficient 26
Table 5 – Hash functions for key exchange

RSA Phase out (2; 3)

DH 27
Insufficient
Changes to RSA for digital signatures
ECDH27
The digital signature scheme to prove possession of an RSA
KRB5
secret key has been replaced in TLS 1.3. A modern padding scheme
NULL (RSA-PSS) replaces the previous RSA-PKCS#1 v1.5 padding
PSK scheme. This improvement applies retroactively: it is required for
servers that support both TLS 1.2 and TLS 1.3. Use the latest
SRP available version of your TLS software library to make use of these
Table 4 – Algorithms for key exchange improvements.

Algorithms for bulk encryption31

Use ECDHE over DHE
During the application phase, (data) records are encrypted in bulk
Elliptic curve cryptography is now widely deployed. Cryptography by a symmetric encryption algorithm. A symmetric encryption
based on elliptic curves (ECDSA, ECDHE) is the fastest choice for algorithm usually consists of a cipher and a mode of operation.
TLS servers. Algorithms that tightly integrate authentication and encryption in
one mode of operation are to be preferred. These so-called AEAD
Before the broad availability of elliptic curve cryptography, DHE was algorithms include AES-GCM and ChaCha20-Poly1305. The most
the only mechanism to achieve forward secrecy in TLS. With the popular symmetric encryption algorithm is AES. TLS supports AES
availability of elliptic curve Diffie-Hellman ephemeral (ECDHE) with two key sizes (128 and 256 bits), while ChaCha20-Poly1305
this is no longer the case. These guidelines advise the use of supports a single (256 bits) key size.
ECDHE over DHE for performance reasons.

Hash functions for key exchange28, 29

The certificate owner uses a digital signature during the key
exchange to prove ownership of the secret key corresponding to
the certificate. The owner creates this digital signature by signing
the output of a hash function. The use of a secure hash function is
important for this purpose.

Note: The following table differs from the others in this chapter by
the reversed effect of Phase Out. It encourages support of modern
hash functions instead of prohibiting weaker alternatives, because
these are required in TLS 1.2.

26 DHE is classified Sufficient and not Good because it is very slow when
secure parameters are used.
27 Static (EC)DH requires special certificates and is seldom used in TLS.
Their use is Insufficient because rarely used code sees less testing and 30 Note that SHA2 support for signatures is generally a property of a TLS
has a higher chance to contain undiscovered vulnerabilities. software library, not a configuration. An update to your library may be
28 This section covers the use of hash functions for key confirmation and required if you do not support the use of SHA2 for key exchange.
handshake integrity. The use of hash functions for key derivation is 31 These are the most common algorithms for bulk encryption. Other Good
covered under Hash functions for bulk encryption and the generation of random algorithms are AES-{256,128}-CCM. CAMELLIA is Sufficient. Other
numbers. Phase out algorithms include SEED and ARIA. These algorithms are
29 These are the most common algorithms for hashing. SHA-224 is also rarely used. If a system supports these algorithms it is worth checking if
Sufficient but not used much. this is necessary.
18 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Algorithm Status Caution: SHA-1 is only Sufficient for bulk encryption and as a
AES-256-GCM Good (3) component in the generation of random numbers. It is Insufficient
for use in digital signatures on certificates, as stated in the section
ChaCha20-Poly1305 Hash functions for certificate verification. Its use as part of the key
AES-128-GCM exchange without supporting newer alternatives is also
Insufficient, as stated in the section Hash functions for key exchange.
AES-256-CBC Sufficient (4)

AES-128-CBC

3DES-CBC Phase out32 (2; 3) Key sizes and choice of groups

AES-256-CCM_833 Insufficient

AES-128-CCM_8 32
RSA key size
The security of RSA for encryption and digital signatures is tied to
IDEA
the key length of the public key.37
DES

RC4 Length of RSA-keys Status

NULL At least 3072 bit Good (2; 3)

Table 6 – Algorithms for bulk encryption 2048 – 3071 bit Sufficient (2)

Less than 2048 bit Insufficient

Hash functions for bulk encryption and the generation of random
Table 8 – RSA key size
numbers
Some algorithms for bulk encryption use hash functions to provide
authenticity (MAC).34 The security of the chosen hash function is Supported elliptic curves38
important for this purpose. Not all elliptic curves are suitable for use in TLS. The security of
ECDSA and EdDSA digital signatures and the ECDHE key exchange
TLS also uses the selected hash function as a component in the depend on the chosen curve. The table lists the most commonly
generation of random numbers (PRF). The security of the chosen used curves.
hash function is also important for this purpose.
Elliptic curve Status
Algorithm 35, 36
Status
secp384r1 Good (3; 4)
HMAC-SHA-512 Good (3; 4) secp256r1
HMAC-SHA-384 curve 448
HMAC-SHA-256 curve 25519
HMAC-SHA-1 Sufficient (3; 4) secp224r1 Phase out (3; 4)
HMAC-MD5 Insufficient (3) Other curves Insufficient
Table 7 – Hash functions for bulk encryption and the generation of random numbers
Table 9 – Supported elliptic curves

Supported finite field groups

32 3DES-CBC is a legacy cipher with a 64 bit block size. Faster and safer The security of the Diffie-Hellman ephemeral key exchange (DHE)
alternatives are widely available and 3DES-CBC is seldom necessary for
compatibility. The limited block size makes 3DES-CBC vulnerable under depends on the lengths of the public and secret keys used within
very specific circumstances (Sweet32-attack). 3DES-CBC is the only the chosen finite field group. The larger key sizes required for the
algorithm for bulk encryption available in TLS 1.0 that is not Insufficient. use of DHE come with a performance penalty. Carefully evaluate
Once you stop supporting TLS 1.0 you should disable 3DES-CBC.
and use ECDHE instead of DHE if you can.
33 AES-CCM_8 is a variant of AES-CCM with a truncated authentication tag,
which has a lower security equivalent for integrity protection.
34 AEAD algorithms tightly integrate authentication and do not use a
separate hash function for record protection. When a cipher suite that
includes an AEAD refers to a hash function, it is only used as a 37 It is tied to the public modulus, which is part of the public key.
component in the generation of random numbers.
38 These are the most common elliptic curves in TLS. Secp521r1 is Good.
35 These are the most common algorithms for hashing. SHA-224 is also The curves brainpoolP512r1, brainpoolP384r1 and brainpoolP256r1 are
Sufficient but not used much. Sufficient. These elliptic curves are rarely used in TLS and therefore not
36 Other documents may refer to these algorithms without the added to the table. If a system supports these curves it is worth checking
HMAC- prefix. if this is necessary.
19 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Standardized finite field groups

Consider the trade-offs involved with application-level compres-
These guidelines advise the use of standardized groups. Larger sion. If you choose to use application-level compression, verify if it
groups are chosen to mitigate against the risk of precomputation is possible to mitigate related attacks at the application level.
by attackers. An example of such a measure is limiting the extent to which an
attacker can influence the response of a server.
This conservative approach enlarges the performance penalty
that comes with the use of DHE. Carefully evaluate and use ECDHE Compression option Status
instead of DHE if you can.
No compression Good

Application-level compression Sufficient 40

The complexity associated with free choice of finite field groups TLS compression Insufficient 41
has been a source of vulnerabilities in the past. The TLS 1.3
specification only includes a limited number of finite field groups Table 11 – Compression

for DHE to reduce this complexity. These guidelines limit Sufficient

groups for TLS to those used in TLS 1.3 (and specified in RFC 7919). Renegotiation
Older versions of TLS (prior to TLS 1.3) allow forcing a new
Finite field group Status handshake. This so-called renegotiation was insecure in its
original design. The standard was repaired and a safer renegotia-
ffdhe4096 (RFC 7919) Sufficient39 (4)
tion mechanism was added. The old version is since called insecure
ffdhe3072 (RFC 7919) renegotiation and should be disabled.
ffdhe2048 (RFC 7919) Phase out
Allowing clients to initiate renegotiation is generally not necessary
Other groups Insufficient
and opens a server to DoS-attacks inside a TLS connection. An
Table 10 – Supported finite field groups attacker can perform similar DoS-attacks without client-initiated
renegotiation by opening many parallel TLS connections, but these
are easier to detect and defend against using standard mitigations.
Options
Insecure renegotiation Status

Off42 (or N/A for TLS 1.3) Good

Compression
The use of compression can give an attacker information about the On Insufficient
secret parts of encrypted communication. An attacker that can Table 12 – Insecure renegotiation
determine or control parts of the data sent can reconstruct the
original data by performing a large number of requests. Data that
contains more repetitions results in better compression than data Client-initiated renegotiation Status
without repetitions. An attacker can thus establish if a known part
Off (or N/A for TLS 1.3) Good
occurs more often in the data sent. This way, use of compression
can negatively impact security. On Sufficient
Table 13 – Client-initiated renegotiation
TLS compression is used so rarely that disabling it is generally not a
problem. This is different for application-specific compression. For
example, compression in the HTTP protocol is commonly used to
make more efficient use of available bandwidth.

40 The use of application specific compression (such as HTTP compression)

results in a TLS configuration that is vulnerable to the BREACH attack.
Disabling application specific compression may have a negative effect
39 These groups are Sufficient and not Good solely because they are slow. on system performance.
DHE key exchange with larger group sizes is significantly more resource
intensive than a security equivalent ECDHE exchange. The groups 41 The use of TLS compression results in a TLS configuration that is
ffdhe6144 and ffdhe8192 (RFC 7919) are also Sufficient, but even vulnerable to the CRIME attack.
slower. 42 Some call this “secure renegotiation”.
20 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

0-RTT OCSP stapling

Old versions of TLS use a minimum of two round trips of communi- The TLS client can verify the validity of the X.509 certificate
cation between client and server before application data is presented by the server by contacting the certificate supplier using
transported. TLS 1.3 halves this overhead by requiring only a single the OCSP-protocol. OCSP provides a certificate supplier with
round of communication. 0-RTT is an option in TLS 1.3 that further information on clients communicating to the server: this may be a
reduces this overhead. It transports application data during the privacy risk. A server can also provide OCSP-responses itself (OCSP
first handshake message. The trade-off is that 0-RTT does not stapling). This solves this privacy risk, does not require connectivity
provide protection against replay attacks at the TLS layer and is between client and certificate supplier and is faster.
therefore hard to use securely in an application agnostic
environment. OCSP stapling Status

On Good
0-RTT Status
Off Sufficient
Off (or N/A prior to TLS 1.3) Good
Table 15 – OCSP stapling
On Insufficient
Table 14 – 0-RTT
21 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Appendix A –
Further considerations

Session tickets are much like session IDs. A session ticket is an

Forward secrecy encrypted copy of the session state. By asking the client to keep a
session ticket, the server no longer needs to store session ID and
Forward secrecy is a mechanism to maintain the confidentiality of state for each client. The client retains the session ticket and
past TLS communications in the event the secret key of a certificate presents it to the server when resuming a connection. The server
is stolen from the server. Configurations that use ECDHE or DHE for decrypts the session ticket, recovers the session state and the TLS
key exchange, offer forward secrecy. connection proceeds directly to the application phase. The server
needs to keep a ‘session ticket encryption key’ for this purpose.
If forward secrecy is used, client and server do not directly use their
own keys for bulk encryption. A second, temporary, (ephemeral) The design of session tickets in TLS 1.0, 1.1 and 1.2 is fragile.43
key is agreed upon instead that is only used for that session. An attacker that steals the session ticket encryption key can do
All values used are destroyed afterwards. The ephemeral key used passive decryption on all connections that exchange or use session
cannot be derived from the secret key of the certificate. Without tickets. This also breaks the forward secrecy property described
forward secrecy, the server’s keys (corresponding to its certificate) previously.
are used to exchange session keys directly.
These issues have been corrected in TLS 1.3. The NCSC advises
The scenario that forward secrecy protects against consists of two organisations that want to speed up session resumption to use
steps. First, an attacker needs to eavesdrop on the communication TLS 1.3. If session tickets are used in older version of TLS, the
that is protected by TLS. Then, the attacker needs to obtain the ‘session ticket encryption key’ should not be stored on disk and
secret key corresponding to the public key in the certificate, for rotated frequently.
example by hacking or the use of a court order. With access to the
secret key, an attacker can recover the session key, decrypt the
encrypted traffic and thus break the confidentiality of Random number generators
communications.
To ensure the security of cryptographic algorithms, a good source
of entropy and a good generator of random numbers (pseudo
Session tickets random number generator, PRNG) are required. The source of
entropy supplies random data and is input to the PRNG. The PRNG
In many applications, it is common for the client and server to turns this random data into uniformly distributed random
(re)establish more connections after an initial TLS connection has numbers. In particular, the requirement for randomness is relevant
been set up. TLS offers mechanisms for session resumption to for (but not limited to):
allow a client and server to skip the handshake and go straight to - the generation of keys for certificates;
the application phase. This reduces the cost of TLS session setup for - the generation of temporary keys and proof of secret key
additional connections. possession for forward secrecy.

With Session IDs, both client and server save session state referenced
by an ID. The client presents that ID when resuming a connection. 43 Drew Springall, Zakir Durumeric, and J. Alex Halderman. “Measuring the
security harm of TLS crypto shortcuts.” Proceedings of the 2016 Internet
Using this Session ID both client and server retrieve the correspond- Measurement Conference. ACM, 2016. https://jhalderm.com/pub/papers/
ing state and proceed directly to the application phase. forward-secrecy-imc16.pdf
22 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Generating sufficient entropy may be a bottleneck if a TLS server is - Files on the server The administrator of the server needs to
under heavy load. The addition of a hardware module (hardware include intermediate CA’s between the root CA and the issued
random number generator) to the server ensures the availability of certificate on the server. The server offers these during TLS
sufficient entropy. Many modern processors integrate a hardware connections. The secret key needs to be adequately protected.
module to harvest randomness. An attacker that can obtain the secret key can read or manipu-
late intercepted traffic. A secret key can be stored in an HSM. An
Most operating systems and TLS software libraries contain a good HSM is designed to offer physical protection against extraction
random number generator. You can ask the supplier of your chosen of the secret key.
TLS library (or the vendor that embeds it) about the random - Administration Keep an administration of all certificates that
number generator that is used and its source of entropy. are in use within the organisation. If a certificate needs to be
replaced, this will make it easier to determine where it is in use.
It is known that the following random number generator is Include the expiration time for all certificates, to ensure timely
insecure: replacement. Expired certificates should never be used. Some
- Dual EC DRBG44, 45 certificate issuers support mechanisms for automated renewal
and deployment of certificates, which may reduce the potential
It is advisable to check that your TLS software library does not use for human error.
this insecure random number generator.

Where does a TLS connection

Certificate management terminate?
Acquiring and managing certificates is not part of these guidelines.
However, good certificate management is an important condition The model of a client that connects to a server does not correspond
for the safe deployment of TLS. That is why we list some points of to a setup that many organisations use. For example, decryption of
particular interest. Further instructions can be found in the TLS traffic can be centralised before it is further routed within an
factsheet “Secure administration of digital certificates” by the internal network. This setup enables the post-processing of
NCSC.46 network traffic. Keep in mind that TLS in such a setup only protects
- Secret key generation Use a good random number generator to up to the point where the connection terminates. Take additional
generate the secret key. Make sure you generate this key on a measures if confidentiality and integrity need to be guaranteed
trusted system, for example a Hardware Security Module (HSM) within the organisation. A possible measure is to use a new TLS
or a computer that is physically disconnected from the internet. session for this last leg.
A key generated on a disconnected computer is then deployed
on the server that will offer the certificate. Some organisations that provide DDoS mitigation services ask for
- Certificate supplier Choose a trustworthy certificate supplier the secret keys of certificates that are used for TLS. They then
to supply and sign the certificate. Organisations within the proceed to terminate and filter your traffic. If you want to make use
Dutch government may make use of certificates by PKIoverheid, of these services, do not simply provide your secret key. This may be
and for certain applications are obligated to do so. in violation of internal policy or (sectoral) law. Consider switching
- Domain names The certificate contains a list of domain names to a supplier that does not require you to hand over keys.47 Identify
(fully qualified domain names, FQDNs) that it applies to. Make the risks associated with handing over secret keys. Take contractual
sure the certificate covers all domains for which it is used, measures to compensate for the decreased technical control and
including subdomains. audit the supplier to assess the extent to which the supplier
- Extended validation Many certificate issuers also issue implements the agreed upon measures.
Extended Validation (EV) certificates. An EV certificate provides
some assurance on the identity of the owner. Developers of
client software have been removing the prominent visual
distinctions between EV and normal certificates. EV certificates
are usually more expensive than a normal certificate. A risk
analysis can help to determine if an EV certificate is warranted.

44 https://csrc.nist.gov/publications/nistbul/itlbul2013_09_supplemental.
pdf
45 https://projectbullrun.org/dual-ec/
46 https://www.ncsc.nl/documenten/factsheets/2019/juni/01/ 47 See the following as an example of a method to achieve this: https://
factsheet-veilig-beheer-van-digitale-certificaten blog.cloudflare.com/keyless-ssl-the-nitty-gritty-technical-details/
23 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Post-quantum security Certificate pinning and DANE

Regular use of TLS is not post-quantum secure.48 It is possible to A client that starts a TLS session with a server, checks the X.509
configure TLS to provide limited49 post-quantum security. The certificate of the server. The client checks the chain of digital
NCSC advises to get specialist support for use cases that have this signatures that connects the certificate to the root CA. This PKI
requirement. For the Dutch government, such support is available system is fragile because most software trusts hundreds of root
from the national communication security agency NBV. CAs. If a certificate supplier issues forged certificates the integrity
of the entire system is at risk.

Authenticating clients with Are you in control over software of both client and server? Then,
certificate pinning enables you to pin just the certificate(s) that the
certificates client should accept. The client no longer has to check the chain of
signatures: it recognizes the certificate or it does not. A compromised
TLS supports mutual authentication with certificates. In mutual certificate authority is no longer a risk for the connection.
authentication, the client uses a certificate to authenticate itself to Alternatively, use of certificates supplied by one particular CA can
the server in addition to the server using a certificate to authenti- be whitelisted by pinning the intermediate or root certificate that
cate itself to the client. are used to issue them. This way, the compromise of other CAs is no
longer a risk. The connection between an app on a mobile platform
Client certificates often contain sensitive information, such as and a server is a scenario where certificate pinning can be effective.
personal data. An example is the name of the user. Before TLS 1.3, Account for the propagation delay of changes in certificate
certificates were transmitted unencrypted as part of the handshake. pinning. Clients will refuse to connect to your server after a (rapid)
If you use certificates that contain sensitive data for authentication change of certificate(s) if a pin cannot be updated in time.
and rely on TLS to provide confidentiality, it is recommended to use
TLS 1.3. DNS-based Authentication of Named Entities (DANE) is a technique
to enable clients to authenticate a certificate based on the Domain
Name System (DNS). The administrator of the certificate publishes
information about that certificate in a special DNS record, a TLSA
record. This allows clients to verify the authenticity of the certificate
using the PKI, but also using the TLSA record. Note that the
traditional DNS system is not trustworthy enough to use DANE.
The use of DNSSEC is necessary. An example of the use of DANE is to
authenticate TLS connections between e-mail servers.50

48 More information about the implications of quantum computers for

organizations can be found in the factsheet “Post-quantum
cryptography”. https://english.ncsc.nl/publications/factsheets/2019/ 50 More information on DANE and this use case can be found in the
juni/01/factsheet-post-quantum-cryptography factsheet “Secure the connections of mail servers”.
49 At the time of writing, such configurations lack post quantum forward https://english.ncsc.nl/publications/factsheets/2019/juni/01/
secrecy. factsheet-secure-the-connections-of-mail-servers
24 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Appendix B –
Changes to these guidelines

These guidelines will be updated for new versions of TLS and new
insights into the (in)security of certain configurations. The security
of TLS is the continuous subject of research. The coming years will
bring the discovery of additional vulnerabilities. In addition,
additional versions or configurations of TLS will be standardized.

Validity
The latest version of these guidelines can always be found on the
website of the NCSC. The NCSC periodically evaluates the validity of
its advice. These guidelines are valid unless updated and do not
expire.

Critical changes
If an immediate change of these guidelines is required, it will be
published as an addendum to the most recent version of the
guidelines. This may occur if research shows that certain TLS
configurations have become insecure.
An addendum will be published on the website of the NCSC and
communicated to NCSC partners. A publication of an addendum
will also be announced using the Twitter account of the
NCSC (@ncsc_nl) or a then suitable medium.

New versions
Larger changes will be implemented in newer versions of these
guidelines. A new version of the guidelines includes information
that was part of earlier addenda. New versions will be distributed in
the same manner as addenda: published on the website of the
NCSC, sent to NCSC partners and using the NCSC Twitter account.
25 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Appendix C –
List of cipher suites

Using TLS the client and server agree on an algorithm selection to TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA25652
use in subsequent encrypted communication. TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA38452
An algorithm selection is a set with four elements, one crypto- TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA25652
graphic algorithm for key exchange, one cryptographic algorithm TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA25652
for digital signatures, one cryptographic algorithm for bulk TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
encryption and one cryptographic algorithm for hashing. In TLS TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
1.3, the set containing only these last two elements is known as a TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
cipher suite. Prior to TLS 1.3, a cipher suite referred to what these TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
guidelines call an algorithm selection. TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
This appendix provides an overview of cipher suites and their TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
security level. This notation can be useful when configuring TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
software. Refer to Figure 1 in the chapter Guidelines illustrates the TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
cipher suite notation in TLS prior to TLS 1.3. TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
Not included in the cipher suite notation are: versions; hash functions TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
for certificate verification; hash functions for key exchange; key sizes & choice TLS_DHE_RSA_WITH_AES_256_CBC_SHA
of groups; and options. These can be found in their respective TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
sections in the chapter Versions, algorithms and options. For ordering, TLS_DHE_RSA_WITH_AES_128_CBC_SHA
refer to the section Prefer faster and safer algorithms in the same
chapter.
Phase out
Good TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_AES_256_GCM_SHA38451 TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_CHACHA20_POLY1305_SHA25651 TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_AES_128_GCM_SHA25651 TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
Sufficient TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA38452 TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA25652

51 When used in combination with Good algorithms for key exchange and
certificate verification. See Figure 2 in chapter Versions, algorithms and
options for an example that results in a lower security level.
52 These algorithm selections, combined with TLS 1.3 are Good. However,
the (old) ciper suite notation used here will frequently result in the use of
at most TLS 1.2 in software, which is Sufficient.
26 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Appendix D –
Glossary

Glossary

3DES See Bulk encryption

AEAD Algorithms for Bulk encryption that provide Authenticated Encryption with Associated
Data (AEAD) tightly integrate authentication and encryption. Popular AEAD algorithms
for Bulk encryption include AES-GCM and ChaCha20-Poly1305.

AES See Bulk encryption

Algorithm selection An algorithm selection is a set with four elements, one cryptographic algorithm for key
exchange, one cryptographic algorithm for digital signatures, one cryptographic
algorithm for bulk encryption and one cryptographic algorithm for hashing. In TLS 1.3,
the set containing only these last two elements is known as a cipher suite. Prior to TLS
1.3, a cipher suite referred to what these guidelines call an algorithm selection.
Using TLS the client and server agree on an algorithm selection to use in subsequent
encrypted communication. See key exchange, digital signature, bulk encryption, hash
function and cipher suite.

Bulk encryption Bulk encryption is the process during the application phase whereby data is enciphered
using the key established during key exchange. Encipherment uses an algorithm for
symmetric encryption. Well-known examples of such algorithms are AES-GCM,
ChaCha20 and 3DES-CBC.

CA See Certificate verification

CAMELLIA See Bulk encryption

CBC See Mode of operation

CCM See Mode of operation

Certificate See Certificate verification

Certificate verifica- The server offers a certificate to the client during a TLS session. This certificate is digitally
tion signed by a certificate authority (CA). The certificate authority is a trusted entity for the
client. The client verifies the digital signature by the certificate authority. This establishes
whether the certificate has been issued by the certificate authority. The algorithm for
certificate validation is the algorithm the certificate authority uses for its digital
signature. Well-known examples are RSA and ECDSA.

ChaCha20-Poly1305 See Bulk encryption

Cipher suite A cipher suite contains an algorithm for bulk encryption and an algorithm for hashing.
Cipher suites before TLS 1.3 also include the algorithms for key exchange and digital
signatures. These guidelines follow the new narrow TLS 1.3 definition for cipher suite.
See algorithm selection.
27 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Glossary

DANE DNS-based Authentication of Named Entities (DANE) is a technique to enable clients to

authenticate a certificate based on the Domain Name System (DNS).

(D)DoS attack A Denial of Service (DoS) attack is an attack whereby a computer is made unavailable, for
example by means of a flood of requests. The requests originate from a single computer
system. In a Distributed Denial of Service (DDoS) attack, requests originate not from a
single but from a large number of computer systems.

DES See Bulk encryption

DHE See Key exchange

Diffie-Hellman See Key exchange

DNS The Domain Name System (DNS) is a distributed system to answer queries for informa-
tion on domain names. A typical query may concern the IP-address of a computer
corresponding to a domain name, or the computer that handles the e-mail for a
particular domain name. DNS Security Extensions (DNSSEC) can improve the trustworthi-
ness of information in DNS. DNSSEC also enables the use of DNS for new purposes, such
as DANE.

DNSSEC See DNS

DSS See Certificate verification

ECDHE See Key exchange

ECDSA See Certificate verification

ECC See Elliptic curve

EdDSA See Certificate verification

Elliptic curve See Mathematical structure

Finite field See Mathematical structure

Forward Secrecy Forward secrecy is a mechanism to maintain the confidentiality of past TLS communicati-
ons in the event the secret key of a certificate is stolen. Cipher suites that employ key
exchanges based on ECDHE or DHE offer forward secrecy.

GCM See Mode of operation

Handshake The handshake is the phase of the TLS protocol where client and server agree on the way
data is to be exchanged. The handshake phase is followed by the application phase where
client and server exchange enciphered data.

Hash function A hash function is a mathematical function that maps input data into a digital fingerprint.
In general, the input is no longer retrievable from the result. Hash functions are used in
TLS as a component in digital signatures, the generation of random numbers (PRF) and
for bulk encryption (MAC). Examples of hash functions include MD5, SHA-1 and SHA-256.

Hashing See Hash function

https HTTP Secure (https) is a protocol that consists of the establishment of a TLS session that
is then used to exchange HTTP traffic. This way communication with a webserver is
protected against eavesdropping and manipulation in transit.

IETF The Internet Engineering Task Force (IETF) is an organization that designs open standards
for the internet. The standards are documented in so-called Requests for Comments
(RFC’s). The IETF does not have authority to enforce the use of standards that they design.

Key A key is some secret data used for cryptographic computations. Encrypted data can be
decrypted using the corresponding key. In symmetric algorithms for encipherment, the
entire key is secret. In asymmetric algorithms for encipherment, the key consists of two
parts: a public part and a secret part. The public part of the key is called the public key.
This part is not kept secret. The secret part is called the secret key.
28 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

Glossary

Key exchange The client and server in a TLS session need a key to start bulk encryption of data.
Exchanging a key happens using an algorithm for key exchange. A special algorithm is
necessary because the connection is not yet encrypted during the handshake. Examples
of algorithms for key exchange are DHE, ECDHE and RSA.

Mathematical Elliptic Curves and Finite fields are mathematical structures useable for computation.
structure Another example of such a mathematical structure is the set of integers. Elliptic curves
can be used for cryptography, so called Elliptic Curve Cryptography (ECC). EdDSA, ECDSA
and ECDHE are algorithms based on ECC. Finite fields can also be used for cryptography.
DHE is an algorithm based on finite field cryptography.

MD5 See Hash function

Mode of operation An algorithm for bulk encryption can act on blocks of data (block cipher) or on a stream of
data (stream cipher). When using a block cipher, the enciphered blocks need to be safely
joined together. The mode of operation is the way these blocks are joined. Examples of
modes of operations are CBC and GCM.

PKI See Public Key Infrastructure

Secret key See Key

Public key See Key

Public Key Infra- A Public Key Infrastructure (PKI) is a hierarchical ordering of certificates where the higher
structure certificates vouch for the authenticity of lower certificates using a digital signature. If a
client trusts the highest certificates in the PKI, then it can also trust the lower certificates
by checking the signatures on the intermediate certificates. The certificates that a
certificate authority issues together with the root certificate together form a PKI.

RSA RSA is an algorithm for key exchange and certificate verification. See both topics.

Secret key See Key

Security equivalent The security equivalent is a measure to compare the cryptographic strength of crypto-
graphic systems. Security equivalents are expressed in bits. The strength of a cryptograp-
hic system depends on the algorithm used, the key length and the state of art of attacks
on the algorithm. For example: ECDSA used with a key length of 256 bit and AES with a
key length of 128 bit both have a security equivalent of 128 bit, based on the current
understanding of cryptologic attacks on these algorithms.

SHA-1 See Hash function

SHA-256, SHA-384, See Hash function

SHA-512

Software library A software library is software that provides functionality for use by programmers of
other software. By using a software library, a programmer can build upon the work of
others. This way, she does not have to build all functionality by herself. TLS use in
software generally relies on a software library.

SSL Secure Sockets Layer (SSL) is the old name for Transport Layer Security (TLS). Though no
longer called SSL following the release of TLS 1.0 (1999), the acronym SSL remains
popular.

VPN A Virtual Private Network (VPN) is a network consisting of computers connected by

non-trusted links. Encryption enables the trustworthy exchange of data between these
computers.
29 | ncsc | IT Security Guidelines for Transport Layer Security (TLS)

References

1. CA/Browser forum. CA/Browser Forum Baseline Requirements.

CA-Browser Forum BR 1.7.3. [Online] October 2020.
https://cabforum.org/baseline-requirements-documents/
2. Federal Office for Information Security (BSI). Cryptographic
Mechanisms: Recommendations and Key Lengths.
BSI TR-02102-1 v2020-01, [Online] October 2020.
https://www.bsi.bund.de/SharedDocs/Downloads/EN/BSI/
Publications/TechGuidelines/TG02102/BSI-TR-02102-1.
pdf?__blob=publicationFile&v=8
3. ECRYPT-CSA. Algorithms, Key Size and Protocols Report (2018),
H2020-ICT-2014 – Project 645421, D5.4, [Online] February 2018.
http://www.ecrypt.eu.org/csa/documents/D5.4-
FinalAlgKeySizeProt.pdf
4. Federal Office for Information Security (BSI). Cryptographic
Mechanisms: Recommendations and Key Lengths, Part 2 – Use
of Transport Layer Security (TLS). BSI TR-02102-2 v2020-01,
[Online] October 2020. https://www.bsi.bund.de/SharedDocs/
Downloads/EN/BSI/Publications/TechGuidelines/TG02102/
BSI-TR-02102-2.pdf?__blob=publicationFile&v=10
Colophon

Publication
National Cyber Security Centre (NCSC)
P.O. Box 117, 2501 CC  The Hague
Turfmarkt 147, 2511 DP  The Hague
+31 (70) 751 55 55

More information
www.ncsc.nl
[email protected]
@ncsc_nl

version 2.1 | January 2021

This information is not legally binding.