HTTPS and Java - Pitfalls and Best Practices - Part 3

Ciphers

So far, we’ve looked at how certificates can support the Authentication property of HTTPS. The certificate also enables a second property of HTTPS – Encryption of the traffic. This encryption is possible because the certificate contains a public key which allows clients to encrypt data, so only those holding the corresponding private key (the website owner) will be able to decrypt.

This encryption is achieved using ciphers. There may be a range of ciphers available on both ends of the connection, and the cipher chosen for the communication will be agreed in the initial TLS handshake. If no cipher can be agreed upon – say if the web server wants to use a strong, modern cipher such as AES 256, and Java cannot support that cipher, then Java will fail to connect with the message we saw earlier: Received fatal alert: handshake_failure.

AES (Advanced Encryption Standard) is considered a highly secure cipher – it’s good enough to be approved for Top Secret material held by the National Security Agency in the USA. AES is available in several strengths, including 128 bit and 256 bit which is the strongest. Before 2018, 128 bit AES encryption was available in Java, but if you wanted the stronger 256 bit version, you’d need to install the Unlimited Strength Jurisdiction Policy files. The reason for this was that historically, the USA controlled the export of strong encryption technology very carefully. 256 bit AES is now available in Java without any additional installation, but only since an update to Java released around January 2018.

So if you’re running a version of Java which does not have AES 256 available and enabled, then it cannot be used as a cipher to encrypt traffic. Depending on the web server configuration, this will either result in the “handshake failure” error message, or communications may fall back to a weaker cipher.

As well as adding stronger ciphers, Java updates also remove support for old ciphers which are known to be insecure. One example of this is RC4, which has been around for a while (it was first designed in 1987). This cipher is now known to have multiple vulnerabilities, and has been disallowed by updates to the TLS specification since 2015. RC4 was removed in Java 8 Update 60, so any versions of Java which still support RC4 can be considered insecure in this context. So, if you are using a version of Java earlier than this, then it’s possible HTTPS traffic could use this weak cipher and be vulnerable.

So keep your Java installations up to date, including minor releases, to keep up to date with security standards.

Read on to the final Part 4 to learn about Perfect Forward Security.