If you are developing web applications that use HTTPS, it could happen to you this year (2015) that, all at a sudden, your browser refused to open the pages from your very own web application. And all this because some Diffie-Hellman public key, which appears to be weak. E.g. if you are using Google Chrome browser, most probably you started to see this problem after upgrading Chrome to version 45. The error message:
Server has a weak, ephemeral Diffie-Hellman public key
It actually means – your server’s DHE (Diffie-Hellman ephemeral key agreement) cipher, that allows Internet protocols to agree on a shared key, has less than 1024 bits. It is described in detail at weakdh.org. This problem could compromise connection security by the men-in-the-middle attack Logjam.
As of Java applications, and I assume your project uses Java 6 or Java 7, the main problem is that your application server (e.g. Apache Tomcat) is using by default Java Security Socket Extension (JSSE), which has it’s own DHE parameters which are 768-bit. This is considered weak and most recent versions of the browsers will refuse to establish a secure connection with your application server.
First solution attempt (client side)
Most probably you will have this problem only with self-signed certificates you are using in your development or staging environments, located within your local network infrastructure. And, since you (and a closed group of users) are affected by this issue, the first attempt to resolve this problem is at the client side, by “forcing” browsers to ignore this issue. If you are lucky enough and you and your colleagues are using Firefox browser, you can tweak this by:
open about:configpage (type it in a browser address bar)
- search for “dhe”
- set parameter
- set parameter
security.ssl3.dhe_rsa_aes_256_sha = false.
There are also Firefox Add-ons you can use to disable weak SSL/TLS ciphers (e.g see this link).
Although this will resolve your problem, at least for Firefox, you should consider another approach – to fix this at the server end.
Server side solution
The straightforward solution at the server end is to migrate to Java 8, if possible. JSSE in Java 8 uses 1024 bits for DHE, by default. This should be strong enough and should resolve the problem.
If you are not able to migrate your application to Java 8, you can exclude DHE ciphers from the server HTTPS Connector. For Tomcat, edit your
server.xml file and add an attribute of HTTPS
Restart Tomcat and try again. You should not get anymore “weak public key” error message in any browser.
Diffie-Hellman public key exchange
Diffie-Hellman key exchange is an algorithm that allows Internet protocols to agree on a shared key which can be used for secure data communication over a public network. It was one of the first public-key protocols.
In short, it works like this:
Each party (in this case both Alice and Bob) create a pair of one private key and one public key. When establishing secure connection, Alice sends Bog her public key and Bob sends Alice his public key. By combining theirs private key and other party’s public key they both get to the same shared secret. This shared secret key is then used to encrypt/decrypt messages Alice and Bob send to each other.
HTTPS, SSL, TLS
Sometimes I hear people using the acronyms HTTPS and SSL interchangeably. Although everybody understands what they mean of (secure HTTP connection between a client and a server), I would like to add hear a short note about those:
- SSL stands for Secure Socket Layer, secure protocol which got to version 3.0
- SSL 3.1 is named TLS 1.0 (Transport Layer Security). This change was due to potential legal issues with the old name, so that the protocol could be “open and free”
- HTTPS is an acronym HyperText Transfer Protocol Secure, but its also called “HTTP over SSL” or “HTTP over TLS”.