Using TLS to protect data

Created:  07 Oct 2016
Updated:  07 Oct 2016
How to configure the services that must be able to receive incoming connections from unknown clients or services.

This guidance outlines how to configure the services that must be able to receive incoming connections from unknown clients or services. Specifically it covers the scenarios of operating a public website and supporting email transfer using Simple Mail Transfer Protocol (SMTP). This guidance does not address use of TLS for Virtual Private Networks (VPNs). 


About TLS

Transport Layer Security (TLS) is a protocol which provides privacy between communicating applications and their users, or between communicating services. When a server and client communicate, well-configured TLS ensures that no third party can eavesdrop or tamper with any message.

At the time of writing, the current version of TLS is version 1.2, which includes security improvements over version 1.0. The predecessor to the TLS protocol was the Secure Sockets Layer (SSL) protocol, all versions of which are now regarded as insecure.


Deploying TLS for web servers

Users accessing an organisation’s digital public services need to have confidence that they are accessing a legitimate service and that their communications remain private and free from interference. TLS is a protocol that provides this security.

TLS used in the context of web servers is known as HTTPS (that is HTTP over TLS).

Selecting protocol versions, cryptographic algorithms and parameters

There are many configuration options that affect the security of a service and communications with it. Unfortunately, selecting the most secure configuration may mean some users are unable to connect to your service. For this reason, you may need to find a balance between security and those users that it's essential the service can reach.

In Mozilla’s advice on Server Side TLS, several TLS configurations are described (‘Modern’, ‘Intermediate’, and ‘Old’) that refer to some of the 'best' security settings possible, depending on the versions of the browsers that need to be supported. Supporting the ‘Old’ profile is risky and should be avoided, as it would mean supporting the insecure SSL protocol.

You should configure the web server to prefer more recent versions of protocols and more secure options first. The server should also be configured not to revert to an older standard after the initial negotiation. Mozilla’s guide provides some good recommendations on how to configure the prioritisation logic of your web server.

For web services that will only be accessed by known (well-maintained) end user devices, then it should be possible to deploy a strict cryptographic profile. In these situations we recommend you use one of the preferred TLS configurations given below.

Secure configuration recommendations

There are a number of good guides that provide configuration advice for HTTPS:

We also recommend the following when deploying your services:

  • publish services only using HTTPS

  • automatically redirect users who visit the HTTP version of your service to the HTTPS version

  • use the latest versions of TLS libraries and supporting web frameworks; implementation issues can introduce vulnerabilities in the libraries which can quickly be exploited if not patched promptly

  • follow the guidance on secure application design from Qualys (see section 4 of Qualys - SSL/TLS Deployment Best Practices) 

  • enable HTTP Strict Transport Security (HSTS) to help the browser secure connections to your service; one or both of the following steps should be taken:

    • add the Strict-Transport-Security HTTP header when the site is accessed over HTTPS - this instructs the browser to only request the HTTPS version in future (until the expiration time in the header elapses)
    • add your sites to the HSTS preload lists which modern browsers use to automatically redirect HTTP traffic to HTTPS ( Chrome’s preload list is included in many of the other browsers’ lists)
  • design new applications to use Content Security Policy, as it can be difficult to retrofit later

  • server certificates should be acquired from trustworthy and reputable sources (see Choosing a Certificate Authority below)

  • use Extended Validation (EV) certificates to further improve the confidence that clients can have in the identity of the service being legitimate
  • ensure you have a means of revoking compromised certificates for your services - you should be able to do this through your chosen Certificate Authority (CA)
  • consider advising users if their web browsers are not supporting a sufficient set of TLS algorithms, and providing them with information on how to upgrade their web browser or operating system if appropriate


Deploying TLS for mail servers

Where email is transferred over untrusted bearers, such as the Internet, its integrity and confidentially should be protected. Whilst it is possible to encrypt and provide integrity for individual emails (by using technology like PGP or S/MIME), this can only be relied upon for protecting message confidentiality if the sender and recipient are using email clients that support these functions and have the required trust infrastructure in place. This is not likely to be practical for all communications with external parties. Therefore we also recommend that internet-facing mail servers (specifically those acting as Mail Transfer Agents - MTAs) be configured to protects emails using the STARTTLS method, as they transfer data between mail servers. The following sections provide advice on the use of TLS to protect SMTP traffic in this way.

Introduction to SMTP security

Connections between SMTP servers acting as MTAs normally use TCP port 25. The SMTP connection between two MTAs can be secured when the connecting party issues the STARTTLS command. When both parties are well configured, this converts an insecure SMTP connection into a secure one, and subsequent SMTP commands are sent over a secure link. We recommend that STARTTLS is supported by all internet-facing MTAs operated by (or on behalf of) your organisation.

Selecting protocol versions, cryptographic algorithms and parameters

We recommend configuring mail servers to support and prefer the preferred cryptographic profile below. Due to the unknown status of connecting parties, they must support weaker cryptographic profiles and protocols, and even support the plain text receipt or transmission of email if you want to be certain of receiving email from some parties.

Between parties with whom you regularly exchange email (eg partner organisations), it is possible to configure connections so that TLS will always be used and that the certificates presented by both mail servers are authenticated to verify the identity of both parties.

Secure configuration recommendations

In order for TLS connections to be established, the application connecting to your service will need to validate the identity of your server by validating the X.509v3 certificate presented by it. This means your service will need a certificate which is signed by an authority that the party connecting to your service recognises and trusts. If you are using a cloud-based email provider this is likely to be done for you, and can be easily tested. However, if you operate your own MTA, you should follow the advice below on choosing a CA and requesting a certificate with strong parameters.

To avoid your domains being used fraudulently (eg for spam or spear-phishing), you should configure Sender Policy Framewrok (SPF), DomainKeys Identified Mail (DKIM) and Domain-based Message Authentication, Reporting & Conformance (DMARC) records to help other mail servers authenticate email they receive from your domains.


Choosing a Certificate Authority

TLS uses X.509v3 certificates to cryptographically validate identities presented by one or both of the communicating parties. If the connecting party is able to validate that the certificate presented to it is issued by a CA it trusts, then secure communications should be established. It is therefore important to choose a CA that is widely trusted by those likely to connect to your services. If selecting a less common CA, it is possible that the certificates presented by your service may not be able to be validated by the connecting party, and the other party may choose not to continue the session.

In order to verify the certificate presented by your server, the web browser or mail server may use its own store of trusted root CAs, or it may refer to the CAs trusted by the operating system. As there is no universal list of trusted CAs, you will need to research support for your chosen CA in the likely web browsers or mail servers and services expected to connect to your service.

Further good advice on what to look for in a CA is set out in section 1.4 of the Qualys - SSL/TLS Deployment Best Practices guide.

Requesting a certificate

In order to have an X.509v3 certificate signed by a CA, you would normally generate your own private key, and send a Certificate Signing Request (CSR) to the CA to be signed, thus keeping your private key secret. There are several parameters you can choose for your private key and signing request. The main choice is whether to support RSA certificates and keys, or Elliptic Curve Cryptography (ECC); either can offer acceptable security. Some mail and web servers support both ECC and RSA, and will select the appropriate certificate based upon the TLS negotiation with the connecting party.

If generating an RSA certificate, we recommend using the following parameters:

  • 2048-bit RSA with SHA256

If generating an ECC certificate, we recommend using the following parameters:

  • ECDSA-256 with SHA256 on the P-256 curve



Given the wide range of configuration options available for TLS, we recommend that you regularly test the configuration of your web servers and mail servers by running automated scans. There are a number of publicly available tools to help test the TLS configuration of your web or mail server. Some tools you may find useful are:

These scans will identify most common issues and configuration problems. They should not be seen as a replacement for skilled penetration testing of your services, but if you have already used tools such as these to help identify and mitigate common issues, then penetration testers will have more time to spend ensuring there are not more subtle or unique flaws in your service.

Note that whilst it is possible for others to test the ability for you to receive email securely, it is not possible for others to test the ability of your services to send email securely without your cooperation. You have to send an email to a testing service, such as that offered by


Recommended cryptographic profiles for TLS

Where support for legacy browsers or applications is not an issue, we recommend you select one of the two cryptographic profiles for TLS:

Combination 1 of the Suite B profile for TLS

A summary of the Suite B profile for TLS is below:


TLS v1.2


AES with 128-bit key in GCM mode

Pseudo-random function

TLS PRF (with SHA-256)


ECDSA-256 with SHA-256 on P-256 curve

Key exchange

ECDH using P-256 curve

Algorithm type



Foundation Profile for TLS

Depending on equipment and infrastructure support, deploying Combination 1 of the Suite B profile for TLS may not be achievable. A suitable alternative is the Foundation Profile for TLS. This profile consists of an RFC-compliant implementation of TLS using the algorithms given in the table below:


TLS v1.2


AES with 128-bit key in CBC mode

Pseudo-random function

TLS PRF (with SHA-256)


X.509 certificates with RSA signatures (2048 bits) and SHA-256

Key exchange

DH Group 14 (2048-bit MODP Group)



Algorithm type



Deviation from this profile, such as through the use of GCM rather than CBC mode, or the use of Perfect Forward Secrecy (PFS), may be required or desirable, and is acceptable.


Was this guidance helpful?

We need your feedback to improve this content.

Yes No