Encryption and data transfer
What are the benefits of encrypting data in transit?
Encrypting personal information while it is in transit from one device to another (eg across the internet or over wired or wireless connections) provides effective protection against interception of the communication by a third party while it is in transit.
Most online services offer this type of encryption by default. For example, to protect against digital eavesdropping. It requires no user intervention to enable. Although encryption in transit is common, it may not be advertised as a feature of such services.
When you transmit personal information, you should use encrypted communications, when available. For example, Hypertext Transfer Protocol Secure (HTTPS) provides secure communication over a network.
Alternatively, you could transform individual files into an encrypted format, as described in the encryption and data storage section. The files then remain protected when you send them over a non-secure communication channel. For example, sending an encrypted attachment over email.
Secure communication methods, such as Transport Layer Security (TLS) or a Virtual Private Network (VPN), can provide you with assurance that the communication’s content cannot be understood if it is intercepted. However, this relies on you using the method appropriately.
Without additional encryption methods in place, such as encrypted data storage, the data will only be encrypted while in transit. This means that it will be stored in the same plaintext form on the recipient’s system as it was stored on the sending organisation’s system.
Other resources
What is HTTPS?
HTTPS is a method for encrypting the content of a webpage between your servers and the user’s browser and protecting user input on your website or mobile applications, or both.
Although the primary purpose of using HTTPS is to encrypt and protect all traffic between a user and a website, it can have other benefits. For example, verifying the identity of the website and indicating that it has not been tampered with.
These additional benefits are not the focus of this guidance and depend on the type of certificate you use and whether you apply HTTPS across your entire site.
What is the difference between HTTPS, TLS, and SSL (Secure Sockets Layer)?
TLS is the successor to SSL. It uses more modern cryptographic protocols. HTTPS is a combination of HTTP with TLS to provide encrypted communication with, and secure identification of, web servers.
When implementing HTTPS on your site or within your app, you might have a choice of what protocols and cipher suites that your server can support. These choices are important. If you use an outdated protocol or an insecure cipher suite, this can compromise the protection HTTPS offers you.
When choosing an appropriate protocol for encrypted transfer, you must not use any versions of SSL. All versions of SSL suffer from a number of well-known vulnerabilities that can compromise the security of personal information. This means that if you do use it, you are not complying with your obligations to implement appropriate security measures to protect that information.
This also means you must not use SSL under any circumstances for a public-facing HTTPS implementation.
Additionally, the Internet Engineering Taskforce (IETF), a key standards organisation for the internet, does not support the use of TLS versions 1 and 1.1. This means those versions are no longer recommended for use.
Browser support for TLS version 1.3 is almost universal. When configured correctly, both TLS 1.3 and TLS 1.2 provide strong protection for data sent between a client and server. TLS 1.3 removes some outdated cryptography and makes certain attacks harder.
You should ensure that your encryption configuration is not susceptible to downgrade attacks which allow an attacker to force your server to use insecure settings.
Further reading
The NCSC’s guidance on TLS states that SSL “must not be used”. SSL is listed in the “Deprecated protocols” section of their guidance.
NCSC guidance on using Transport Layer Security to protect data
Where should we use HTTPS on our website?
If you provide a website, you should use HTTPS across all its pages. This is especially important for safeguarding personal information, such as login credentials, payment information, and any other sensitive details users might share.
HTTPS provides a wide variety of security benefits. There is no longer a compelling argument for not implementing HTTPS across all pages of a website. Some web browsers will warn your users that your site is insecure if your site does not use HTTPS.
The NCSC states that all websites should use HTTPS even if they don’t include private content, sign-in pages or credit card details.
The NCSC also says that organisations should use certain HTTPS-specific features to improve the security of their online services. These include:
- publishing services only using HTTPS;
- redirecting unencrypted HTTP requests to the HTTPS version;
- using HTTP Strict Transport Security (HSTS) to force all connections to use HTTPS instead of unencrypted HTTP; and
- setting up the ‘upgrade-insecure-requests’ directive within Content Security Policy to force all content (including third party content) to load using HTTPS.
How can we test if our HTTPS implementation is effective?
A simple test is to visit your website with a web browser and check whether the padlock icon is visible in the address bar of the browser. If there is no padlock or there is a warning that the site is insecure, it is likely that HTTPS is not correctly implemented on your website.
You could use publicly available online testing services to do this. These services function by performing a test of a web server once you enter a particular web address.
These tests do not require usernames or passwords for administrator controls on your site. If these details are requested, you should not proceed unless you are certain that the testing tool or service is legitimate. Revealing usernames and passwords for controls on your site is a serious security risk and may result in a data breach.
A low rating on any of these tools does not automatically mean that you’re not complying with the security principle. However, you should review your security measures and make improvements, where appropriate.
Are there any risks with encryption and data transfer?
Yes. Even if you encrypt data in transit, there are still occasions where it can be subject to unauthorised access. For example:
- Data that is encrypted in transit is protected against eavesdropping, but if the security protocols are not in place on the recipient’s device, the data may still be at risk once it reaches that device.
- Certain data relating to the communication may still be exposed, such as metadata or DNS queries in an unencrypted form.
- Implementations relying on public-key infrastructure need strict certificate checking to maintain trust.
As with data storage, you should be aware of these residual risks and address these as part of your encryption policy. You could include employee awareness training.