Encryption and data transfer

In more detail

• Why is it important to consider encrypted data transfer?
• What is HTTPS?
• What’s the difference between HTTPS, TLS and SSL?
• Where should we use HTTPS on our site?
• How can we test if our HTTPS implementation is appropriate?
• What are the residual risks with encrypted data transfer?

Why is it important to consider encrypted data transfer?

Encrypting personal data whilst it is being transferred 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 whilst the data is in transfer.

It is also strongly recommended to use encrypted communication when transmitting any data over a wireless communication network (eg Wi-Fi) or when the data will pass through an untrusted network.

Data can be transformed into an encrypted format (see individual file encryption) and transferred over a non-secure communication channel yet still remain protected. An example would be sending an appropriately encrypted attachment via email.

However, use of secure communication methods such as Transport Layer Security (TLS) or a Virtual Private Network (VPN) will provide assurance that the content of the communication cannot be understood if intercepted provided the method is implemented correctly.

It is important to remember that without additional encryption methods in place (such as encrypted data storage) the data will only be encrypted whilst in transit and will be stored on the recipient’s system in the same form as it is stored on the data controller’s system (ie in plaintext).

What is HTTPS?

‘Hypertext Transport Protocol Secure’ or 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 and/or mobile applications.

While the primary purpose of using HTTPS is to encrypt and protect all traffic between a user and a website, it can have other benefits such as verifying the identity of the website, and ensuring that a user can trust the whole website. These additional benefits are not the focus of this guidance, however, and are dependent on the type of certificate you use and whether you apply HTTPS across your entire site.

What’s the difference between HTTPS, TLS and SSL?

TLS and SSL are often used interchangeably to refer to the same concept – the creation of an encrypted communications channel. Essentially, TLS is the ‘successor’ to SSL and 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 will have a choice of what protocols and cipher suites your server will support. These choices are important, as the use of an outdated protocol or an insecure cipher suite can compromise the protection HTTPS offers.

In terms of protocols, you should not support any versions of SSL, and you should ensure that your configuration is not susceptible to downgrade attacks. All versions of SSL suffer from a number of well-known vulnerabilities and should not be supported under any circumstances for a public-facing HTTPS implementation.

You also need to carefully consider the cipher suites that your server will support. Guidance from the National Institute of Standards and Technology (NIST) provides a list of approved suites and also recommends that all cryptography provides at least 112 bits of security. The use of cryptographically broken ciphers such as RC4 is specifically prohibited, and you should avoid their use wherever possible.

Historically, there has been an issue with browsers not supporting the latest TLS protocols. However, browser support for TLS 1.2 is now almost universal, as the chart below demonstrates, and as such you should only use previous versions where there are very specific needs.

Figure 1: : Browser support for TLS 1.2 as of November 2020. Source: https://caniuse.com/#feat=tls1-2. 

You should also ensure that you have documented the potential risks in using an older scheme, as well as the mitigations you have put in place to protect user data.

It should also be noted that TLS 1.3 was approved by the Internet Engineering Task Force (IETF) in March 2018. TLS 1.3 provides a number of improvements over TLS 1.2 and its approval enables the wider implementation of the protocol in software products and browsers. Although TLS 1.2 still provides a high standard of protection you should nevertheless ensure that, if or when required, you are able to support TLS 1.3 in the future.

Where should we use HTTPS on our site?

There are a number of factors to consider when implementing HTTPS on your website. You should have HTTPS across your entire site, although there are circumstances that can make this difficult – mixed origin content being the biggest issue that many sites will encounter. You must ensure that at the very least all pages with user input are protected, and if you are not using HTTPS across your entire site you should ensure that you are not leaking any sensitive information – for example, in referral headers or through failing to use secure cookies. You should also have mitigations against an attacker being able to hijack unprotected pages to redirect users to malicious pages.

Using HTTPS across your entire site is a much better solution as it prevents your non-HTTPS pages from being hijacked to point to malicious links. If you ensure that you redirect all HTTP traffic to HTTPS only, you can then also utilise HSTS (HTTP Strict Transport Security) which provides additional protections against man in the middle attacks.

If you are using a content distribution network or a reverse proxy you need to make sure you have considered where the HTTPS scheme ends, as this could leave user data still being transmitted in an unprotected form.

How can we test if our HTTPS implementation is appropriate?

You do not necessarily need to undertake an external penetration test to check the effectiveness of your HTTPS implementation. There are a number of publicly-available online testing services that you can use to do this. These services function by performing a test of a web server once a particular web address is entered.

A low rating on any of these does not automatically mean that you are not complying with the security principle; however, it is a fairly strong indication you need to review your security measures and make appropriate improvements.

What are the residual risks with encrypted data transfer?

You should recognise that even if a system uses encrypted data transfer there are still occasions where data can be subject to unauthorised access. As with data storage, is important to be aware of these residual risks and address these as part of an encryption policy which should also include employee awareness training. Some examples include:

• certain data relating to the communication may still be exposed (eg metadata or DNS queries) in an unencrypted form; and
• implementations relying on public-key infrastructure must implement strict certificate checking to maintain trust in end-points.