HTTPS and Java - Pitfalls and Best Practices - Part 4

Perfect Forward Secrecy

At the present time, with the possibility of data breaches and digital eavesdropping, privacy is an important subject. What’s to prevent a malicious third-party from collecting traffic going to or from a website?

It might seem adequate to use HTTPS to encrypt traffic to a website, meaning it’s impossible to decrypt the traffic unless you also have access to the private key. But what if a malicious actor collects encrypted traffic over a long period of time? They may not be able to decrypt the traffic just yet … but what if at a later date they recover the private key which secures the website? Would they be able to decrypt all the collected traffic?

To answer this question, we need to look a little deeper at the TLS (Transport Layer Security) protocol, which is used to set up a secure communication channel to a HTTPS website.

Communication with a HTTPS website is encrypted in part with a short-lived, shared secret, known to both parties. This shared secret is derived from the long-living private key which is issued to a website when it is issued with a certificate.

Here’s a short example of how encrypted traffic could be recovered at a later date. If a connection to a HTTPS website uses the RSA key exchange algorithm (now considered insecure), then it is vulnerable to this scenario. When the encrypted session is set up, the client (browser or Java program) decides the shared secret. It encrypts this value using the server’s public key (which is present in the certificate). This encrypted shared secret is then sent to the server, and future secret communications are based on that. So, if the private key of the server was recovered by a malicious third party, then past and future traffic could be decrypted by that party.

To prevent this scenario, key exchange can be carried out with a property known as Perfect Forward Secrecy. This means that communications are encrypted by a one-time, ephemeral session key which exists only for that session. So traffic cannot be decrypted at a later date unless you have the one-time key for that particular session.

Whether Perfect Forward Secrecy is possible depends on the key exchange algorithm selected between the client and server, as part of the TLS handshake. There have been a number of versions of TLS (1.0 to 1.3), each version improving security. The most recent version (1.3) entirely removes support for key exchange algorithms which do not support Perfect Forward Secrecy, such as RSA. Support for TLS 1.3 was added in Java 11, so it can be said that Java 11 can ensure Perfect Forward Secrecy in secure communications, as long as the web server also supports TLS 1.3.

In closing, when developing software, security and privacy should be a high priority. So keep your Java installations up to date!

Don’t be tempted to work around security-related errors when they occur. Instead, understand what they really mean and fix any underlying problems which compromise security.