Force Chrome to Ignore a "weak ephemeral Diffie-Hellman public key”

Question

With the update of Chrome to v45, it's blocking access to pages with weak ephermeral Diffie-Hellman public keys. I understand that this is due to Logjam. I understand that switching from https to http is a "solution" in some cases.

However, I can not switch from https to http because I am auto redirected to https by the web-based software we use on our intranet.

Obviously, the solution would be to have security change the various intranet servers to be secure from logjam, I understand that, but that isn't an option right this minute, and I can not do any more work until it's fixed. Because it's an intranet and simply connecting at all requires that one be physically here, the risk is minuscule.

Is there any way that I can continue to access pages via https protocol, with weak ephemeral Diffie-Hellman public keys in Chrome version 45?

Answer 1

Hacky fix to get around this issue (Mac OSX)

• Run this in commandline to workaround the issue while launching Chrome

Chrome:

open /Applications/Google\ Chrome.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

Canary:

open /Applications/Google\ Chrome\ Canary.app --args --cipher-suite-blacklist=0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013

For Firefox

• Go to about:config
• Search for security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha
• Set them both to false.

NOTE: Permanently fix would be to update the DH key with a length > 1024

Answer 2

Indeed, seems that browsers have taken seriously the Diffie-Hellman issue with lower keys than 1024 in length, which in a part is great news, but on the other hand, it has generated a lot of angry Chrome users.

The fix for this issue (and many others related to security) is sysadmins' responsibility, so as I understand it, the decision of blocking any website that offers a weak 512 bit or lower Diffie-Hellman key is a measure of pressure directed to the ones who manage security on remote sites, with the "downside" of users suffering the effects.

It is currently possible to blacklist some Cipher Suites when launching the Google Chrome browser by running it with the --cipher-suite-blacklist= 0x0088,0x0087,0x0039,0x0038,0x0044,0x0045,0x0066,0x0032,0x0033,0x0016,0x0013 parameter, which seem to disable the ones related to the LogJam vulnerability and permits users join the sites, but I insist that it should be sysadmins' responsibility to fix the issue with their Diffie-Hellmann's keys.

Answer 3

Faced same problem. If you are server side guy just add the following lines in 443 connector in server.xml tomcat

sslProtocols="TLSv1, TLSv1.1, TLSv1.2" ciphers="TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256,TLS_RSA_WITH_AES_128_CBC_SHA,TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA,SSL_RSA_WITH_RC4_128_SHA"

This will help you to resolve this SSL key problem.

Answer 4

One of the things you asked was if there was any disadvantage to using the workarounds listed (or using others not listed) in an intranet setup. The short answer is that as long as the servers involved are using weak keys, the servers involved will be susceptible to any system using a logjam attack, and depending on the nature of the server the server may subsequently be a compromised server that may propagate the issue to other clients accessing the server.

Two not unlikely scenarios are a laptop that's been infected off the intranet accessing the internal server when they connect to the intranet again, or a browser configured to ignore the issue (as suggested above and elsewhere) that is currently used to access the internet and which happens to connect to a compromised server being a jumping off point for attacking your intranet servers.

As I am not personally familiar with all of the issues that the logjam flaw presents, I can't say if either of those two situations are particularly likely. My own experience is that sysadmins with Internet facing servers tend to get as far ahead of such issues as they can. That said my experience is also that intranet server admins tend to do things like make sites pretty before addressing server security issues.