Using TLS to protect data

Introduction

This guidance is aimed at system administrators who are responsible for configuring servers or clients within their estate. It explains how to configure TLS securely and transition to post-quantum cryptography (PQC).

The guidance covers:

• transitioning TLS to use PQC, including recommended profiles for its use
• configuring TLS 1.3 and TLS 1.2 using recommended cryptographic profiles
• managing deprecated protocol versions and disabling known insecure TLS features
• using certificates with TLS
• deploying TLS for web and mail services
• testing TLS deployments

About TLS

Transport Layer Security (TLS) is a protocol that provides security for digital communications between two parties. When a server and client communicate, well-configured TLS ensures that no third party can eavesdrop or tamper with any message.

Supported versions

TLS 1.3 is the latest version of TLS. It was designed to be more secure than earlier versions and is the only version that will receive new features in future, such as support for PQC.

TLS 1.2 is still considered to provide strong protection against classical attacks when configured with the recommended cryptographic profiles. However, it will not receive new features apart from critical security updates, as outlined in RFC 9851.

If you use TLS 1.2, you should plan to transition to TLS 1.3 as part of your migration to PQC.

Deprecated protocols

The Secure Sockets Layer (SSL) protocol was the predecessor to TLS. All versions of SSL are deprecated and considered insecure. You must not be use them.

TLS 1.1 and 1.0 have also been deprecated by the IETF, as outlined in RFC 8996, and should not be used. 

The NCSC recommends that government systems do not support deprecated versions of the protocol, and are upgraded to support TLS 1.3 instead.

Post-quantum cryptography in TLS

A cryptographically-relevant quantum computer would threaten the key exchange and digital signature algorithms currently used to secure TLS. The primary mitigation to this risk is to migrate to PQC, in line with the broader NCSC advice on PQC migration.

Post-quantum key exchange in TLS

RFC 10024 standardises three post-quantum/traditional hybrid key agreement mechanisms in TLS 1.3.

• SecP256r1MLKEM768
• SepP384r1MLKEM1024
• X25519MLKEM768

All three are suitable for protecting personal, enterprise and OFFICIAL-tier government information.

These mechanisms combine the post-quantum ML-KEM algorithm with a traditional elliptic curve algorithm. The NCSC recommends using hybrid schemes as an interim measure when migrating to PQC.

The IETF is developing standards for non-hybrid ML-KEM (ML-KEM Post-Quantum Key Agreement for TLS 1.3), which will standardise MLKEM768 and MLKEM1024 as options for TLS. The NCSC considers these algorithms acceptable for use in TLS, and they are already available in many common TLS implementations.

Post-quantum authentication in TLS

At present, the IETF has only standardised post-quantum algorithms for key exchange in TLS. Work is ongoing to standardise post-quantum authentication in TLS and the wider Web PKI, with a number of drafts at different levels of maturity. Organisations operating private PKIs may be able to adopt post-quantum authentication sooner than services relying on the public Web PKI, where standardisation and wider ecosystem adoption are still ongoing.

Once these standards have been finalised, and mature implementations are available in commercial implementations, this guidance will be updated to include recommendations for their use.

Using cryptographically agile deployments, where it is easier to support alternative cryptographic algorithms, will make these and future transitions easier.

TLS 1.3 configuration

TLS 1.3 introduced some major changes. It uses different cipher suite definitions to earlier TLS versions, and has different configuration options. Some implementations separate TLS 1.3 configuration from previous TLS versions. Please consult your implementation documentation to determine how to configure options specific to TLS 1.3.

The recommended profiles include both post-quantum and traditional algorithms to support the transition to PQC. The recommended symmetric cipher suites are unchanged.

The key exchange algorithms included in the recommended profiles are not the only ones the NCSC considers acceptable. All of the post-quantum key exchange algorithms currently specified for use with TLS 1.3 by the IETF offer appropriate protection for personal, enterprise and OFFICIAL-tier government information.

Recommended post-quantum cryptography profiles for TLS 1.3

Recommended traditional cryptography profiles for TLS 1.3

OpenSSL Configuration

The way preferred algorithms and cipher suites are configured varies between TLS platforms. As an example, for platforms built around the OpenSSL library, the following recommended configuration string for TLS 1.3 servers will enable a set of key exchange algorithms (or ‘supported groups’) that aims to optimise security, compatibility and performance:

*X25519MLKEM768:SecP256r1MLKEM768:MLKEM768/SecP384r1MLKEM1024:MLKEM1024/*secp256r1:secp384r1

Client configuration for TLS 1.3

TLS clients should offer key shares and cipher suites that are most likely to be accepted by the server. The configuration of TLS clients is often outside the control of the administrator, but where it is possible to configure clients (for example within a privately hosted enterprise network), the NCSC recommends offering key shares for X25519MLKEM768 and secp256r1. 

Using the recommended profiles for PQC migration

To support PQC in TLS, you should:

• enable TLS 1.3 and prefer it over TLS 1.2 where possible
• enable at least one of the recommended post-quantum key exchange algorithms as soon as your implementation supports them
• enable the recommended traditional key exchange algorithms where you still require compatibility with systems that do not yet support PQC

In most cases, it will be appropriate to combine these activities by adopting TLS 1.3 and enabling and preferring the recommended post-quantum key exchange algorithms as a single migration activity.

Migrating the authentication methods used by TLS 1.3 to post-quantum alternatives will depend on the transition of the PKI infrastructure they rely on, and will need to wait until the relevant standards have been confirmed.

For internet-facing servers and clients, maintaining compatibility with systems that do not yet support PQC is important. As a result, support for traditional cryptography cannot be disabled until much later in the overall PQC migration.

TLS 1.2 configuration

Where client and server implementations support AES-GCM, use one of the recommended profiles below. These both provide equivalent protection.

If AES-GCM is not supported, then the compatibility profile for TLS 1.2.

Recommended Profiles for TLS 1.2

Compatibility Profile for TLS 1.2

Legacy versions

Legacy Profiles for TLS 1.1 and 1.0

TLS versions 1.1 and 1.0 do not support current authenticated encryption cipher suites and have other known vulnerabilities. These versions have been formally deprecated by the IETF, as outlined in RFC 8996, and should no longer be used.

A time-bounded migration plan should be put in place for any government systems using deprecated TLS versions, or cipher suites. Where this is not possible, system owners should consult the NCSC.

The following legacy profiles are defined only for cases where TLS versions 1.1 and 1.0 cannot be disabled. In all other circumstances, the recommended TLS 1.2 or 1.3 profiles should be used, and TLS 1.0 and TLS 1.1 must be disabled.

Third-Party services

When a TLS service is hosted on the infrastructure of a third-party provider, such as a content delivery network (CDN), the TLS configuration may not be under the direct control of the data owner. Service providers will usually allow the data owner to choose a policy that specifies which TLS versions and cipher suites are permitted.

The data owner should choose the most restrictive policy available. This policy should enable TLS 1.3 and where required TLS 1.2, and should include the recommended profiles described in this guidance.

Avoiding security weaknesses in older versions

Older TLS versions include features and cryptographic components that are now known to provide weak security. In most cases, these features are only used in a connection when both the client and server support them.

Using up-to-date software reduces the likelihood of insecure features being used. To avoid some of the most common vulnerabilities, you must disable the following features and components where they are present:

• insecure TLS renegotiation – either by disabling renegotiation, or enabling the Renegotiation Indication Extension, as described in RFC 5746
• insecure TLS protocol downgrade – by supporting the Fallback Signaling Cipher Suite Value, as described in RFC 7507, only where TLS 1.1 or earlier versions are supported
• TLS record compression – as described in RFC 5246, section 6.2.2
• EXPORT ciphers and export key generation – as described in RFC 2246, section 6.3.1

You should also disable support for any deprecated SSL and TLS versions that are not required.

Using TLS 1.3 0-RTT

TLS 1.3 provides an optional zero round trip feature, known as 0-RTT, which allows clients to send data before the full TLS handshake has completed. Unlike most data exchanged in a TLS session, 0-RTT data can be replayed by an attacker. If this risk is not addressed by the application using TLS, it can lead to security vulnerabilities.

Some application protocols built on TLS 1.3 include mitigations for attempted replay attacks, and can safely use 0-RTT mode. You should only enable 0-RTT when you are satisfied that the software and application protocols in use to provide appropriate mitigations.

Using Certificates with TLS