Transport Layer Security (TLS) for external-facing services
Guidance for the secure configuration of Transport Layer Security on servers where handling connections from unknown parties.
Note: This publication is in ALPHA. Please send any feedback to the address platform@cesg.gsi.gov.uk.
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.
This guidance is to support the configuration of public sector 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). Guidance on this topic will be covered in a forthcoming publication.
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.
There are a number of good resources on TLS configuration in the public domain. Where possible, this document refers to several of these resources rather than repeating the good advice they contain.
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, depending on your user base, 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 the users you want the service to 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 which 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 specified below.
Secure configuration recommendations
There are a number of good guides that provide configuration advice for HTTPS:
- Qualys - SSL/TLS Deployment Best Practices
- Google - Webmasters: Secure Your Site with HTTPS
- Mozilla Security/Server Side TLS
In addition to the guidance referenced above, CESG recommends the following for digital public 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, which is included in many of the other browsers’ lists, is available here.
- Design new applications to use Content Security Policy, as it may be difficult to retrofit later.
- Server certificates should be acquired from trustworthy and reputable sources (see below).
- Use Extended Validation (EV) certificates to further improve the confidence that clients can have in the identity of the service being legitimate. Information on EV certificates can be found here.
- 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 (eg using 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 recommend that internet-facing mail servers (specifically those acting as Mail Transfer Agents) be configured to support TLS to protect emails using the STARTTLS method as they transit 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 Mail Transfer Agents (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 configured well, 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 the UK public sector.
Selecting protocol versions, cryptographic algorithms and parameters
We recommend your mail servers be configured to support and prefer the preferred cryptographic profile below. Due to the unknown status of connecting parties, it will be necessary to support weaker cryptographic profiles and protocols, and even to support the plaintext 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 other public sector 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 party 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, or using the PSN mail relays to route your external email, this is likely to be done for you, and is easily tested following our advice below. 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 SPF, DKIM and 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 you use the following parameters:
- ECDSA-256 with SHA256 on the P-256 curve
Testing
Given the wide range of configuration options available for TLS, we recommend that public sector organisations should regularly test the configuration of their 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:
- Qualys SSL Server Test
- Check TLS services from checktls.com
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 checktls.com).
Preferred 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 described below.
Combination 1 of the Suite B profile for TLS
A summary of the Suite B profile for TLS is below:
| Algorithm type | Description |
|---|---|
| Protocol | TLS v1.2 |
| Encryption | AES with 128-bit key in GCM mode |
| Pseudo-random function | TLS PRF (with SHA-256) |
| Authentication | ECDSA-256 with SHA-256 on P-256 curve |
| Key Exchange | ECDH using P-256 curve |
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:
| Algorithm type | Description |
|---|---|
| Protocol | TLS v1.2 |
| Encryption | AES with 128-bit key in CBC mode |
| Pseudo-random function | TLS PRF (with SHA-256) |
| Authentication | X.509 certificates with RSA signatures (2048 bits) and SHA-256 |
| Key Exchange | DH Group 14 (2048-bit MODP Group) |
| Integrity | SHA-256 |
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.
Other information
This guidance is issued by CESG, the UK’s National Technical Authority on Information Assurance. One of the roles of CESG is to provide advice to UK government entities and organisations providing services to UK government. The guidance found here is provided and intended for use by this audience. It is provided ‘as-is’ an an example of how specific requirements could be met. It should be used to help inform risk management decisions on the use of the products described, but it should not be used for procurement decisions; it is not intended to be exhaustive, it does not act as an endorsement of any particular product or technology, and it is not tailored to individual needs. It is not a replacement for independent, specialist advice. Users should ensure that they take appropriate technical and legal advice in using this and other guidance published by CESG.
This guidance is provided without any warranty of any kind, whether express or implied. It is provided without any representation as to the accuracy, completeness, integrity, content, quality, or fitness for purpose of all or any part of it. CESG cannot, then, accept any liability whatsoever for any loss or damage suffered or any costs incurred by any person as a result of, or arising from, either the disclosure of this guidance to you, or your subsequent use of it.
This guidance is © UK Crown Copyright. All Rights Reserved.