Securing Google Chrome Browser against the Logjam exploit on Windows

Question

Is there a way to fix Chrome against the Logjam TLS exploit on Windows? I have updated my Chrome to the latest version yet the https://weakdh.org/ website warns me that "web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser."

Has a fix / patch not been released yet? Meanwhile is there a manual way to fix this?

Chrome Version 43.0.2357.65 m on Windows 7.

Edit: It seems no browser has really rolled out a fixed version yet. Wasn't it a bit premature for the authors of the Logjam paper to release it before the browser teams got a chance to at least prepare a fix? What was the big hurry?

Answer 1

Edit 2015-09-03: Fixed.

Fixed as of Chrome version 45 from 2015-09-01. WeakDH.org now reports:
Good News! Your browser is safe against the Logjam attack.

Most of original post preserved below.

---

Batch Workaround
A workaround is to create a batch file that starts Chrome and explicitly disables all ephemeral DH suites.

There are different blacklists strings floating around the internet at the moment. Below is my attempt.

Cipher suites are identified by their hex ID. And IANA has the official list of registered cipher suites.

But rather than pick and choose from that list, I decided to let OpenSSL (v1.0.2) do that for me. The suites are these:

openssl ciphers -V DHE | sort

0x00,0x11 - EXP-EDH-DSS-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=DSS  Enc=DES(40)   Mac=SHA1 export
0x00,0x12 - EDH-DSS-DES-CBC-SHA     SSLv3 Kx=DH       Au=DSS  Enc=DES(56)   Mac=SHA1
0x00,0x13 - EDH-DSS-DES-CBC3-SHA    SSLv3 Kx=DH       Au=DSS  Enc=3DES(168) Mac=SHA1
0x00,0x14 - EXP-EDH-RSA-DES-CBC-SHA SSLv3 Kx=DH(512)  Au=RSA  Enc=DES(40)   Mac=SHA1 export
0x00,0x15 - EDH-RSA-DES-CBC-SHA     SSLv3 Kx=DH       Au=RSA  Enc=DES(56)   Mac=SHA1
0x00,0x16 - EDH-RSA-DES-CBC3-SHA    SSLv3 Kx=DH       Au=RSA  Enc=3DES(168) Mac=SHA1
0x00,0x32 - DHE-DSS-AES128-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(128)  Mac=SHA1
0x00,0x33 - DHE-RSA-AES128-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA1
0x00,0x38 - DHE-DSS-AES256-SHA      SSLv3 Kx=DH       Au=DSS  Enc=AES(256)  Mac=SHA1
0x00,0x39 - DHE-RSA-AES256-SHA      SSLv3 Kx=DH       Au=RSA  Enc=AES(256)  Mac=SHA1
0x00,0x40 - DHE-DSS-AES128-SHA256   TLSv1.2 Kx=DH     Au=DSS  Enc=AES(128)  Mac=SHA256
0x00,0x44 - DHE-DSS-CAMELLIA128-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(128) Mac=SHA1
0x00,0x45 - DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(128) Mac=SHA1
0x00,0x67 - DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH     Au=RSA  Enc=AES(128)  Mac=SHA256
0x00,0x6A - DHE-DSS-AES256-SHA256   TLSv1.2 Kx=DH     Au=DSS  Enc=AES(256)  Mac=SHA256
0x00,0x6B - DHE-RSA-AES256-SHA256   TLSv1.2 Kx=DH     Au=RSA  Enc=AES(256)  Mac=SHA256
0x00,0x87 - DHE-DSS-CAMELLIA256-SHA SSLv3 Kx=DH       Au=DSS  Enc=Camellia(256) Mac=SHA1
0x00,0x88 - DHE-RSA-CAMELLIA256-SHA SSLv3 Kx=DH       Au=RSA  Enc=Camellia(256) Mac=SHA1
0x00,0x99 - DHE-DSS-SEED-SHA        SSLv3 Kx=DH       Au=DSS  Enc=SEED(128) Mac=SHA1
0x00,0x9A - DHE-RSA-SEED-SHA        SSLv3 Kx=DH       Au=RSA  Enc=SEED(128) Mac=SHA1
0x00,0x9E - DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(128) Mac=AEAD
0x00,0x9F - DHE-RSA-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=RSA  Enc=AESGCM(256) Mac=AEAD
0x00,0xA2 - DHE-DSS-AES128-GCM-SHA256 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(128) Mac=AEAD
0x00,0xA3 - DHE-DSS-AES256-GCM-SHA384 TLSv1.2 Kx=DH   Au=DSS  Enc=AESGCM(256) Mac=AEAD

And here's an ugly little script that I used to just pick the hex IDs from the list above and generate the blacklist string for me:

openssl ciphers -V DHE | 
sort | 
awk '{print $1}' | 
sed 's/,0x//g' | 
xargs echo | 
sed 's/ /,/g' | 
sed 's/^/--cipher-suite-blacklist=/'

And this is the output of that command:

--cipher-suite-blacklist=0x0011,0x0012,0x0013,0x0014,0x0015,0x0016,0x0032,0x0033,0x0038,0x0039,0x0040,0x0044,0x0045,0x0067,0x006A,0x006B,0x0087,0x0088,0x0099,0x009A,0x009E,0x009F,0x00A2,0x00A3

(Disclaimer: This string is probably too long. I don't think Chrome even supports all of these cipher suites. (You could check using the SSL Labs client test.))

Update 2015-07-03: Chrome still vulnerable.

The official Logjam page, https://WeakDH.org/, checks for 512 bit DHE support. It internally uses the https://dhe512.zmap.io/ domain to check. Ability to connect to this domain is rated as a failure.

• Chrome fails.
• Internet Explorer, Safari, Firefox pass.

The actual minimum DHE bit lengths used are these:

• Chrome uses a 512 bits minimum.
• Internet Explorer uses a 1024 bits minimum.
• Safari uses a 768 bit minimum.
• Firefox uses a 1023 (not 1024) bits minimum.

(See also: Wikipedia: Logjam)

Some DH key lengths to test are here:

• https://dh480.badssl.com/, Chrome rejects this with ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY.
• https://dh512.badssl.com/, Chrome accepts this.
• https://dh1024.badssl.com/, Chrome accepts this.
• https://dh2048.badssl.com/, Chrome accepts this.

But: The a 1024 bit minimum has been announced for Chrome 45. (And I think this means September 2015. But I don't really understand the Chrome release model.)

Answer 2

In answer to your second question, for logjam to work, both the client AND the server have to support the old "export 512 bit DH connections". This is fixed by simply re-configuring the webserver to exclude these legacy cipher suites. No patching is required to fix the server in this case, as these cipher suites are long dead as far as being used.

These are very weak ciphers that haven't been commonly used since the previous century, so it's very easy to fix on the server end with no real downside. So that's why the researchers undoubtedly announced the vulnerability rather than wait for the browsers to fix it, and users to upgrade.

Most major websites in fact haven't accepted this legacy cipher suite for a long time, so making a worldwide announcement is the only way to get the word out to everyone who still (likely unknowingly) supported it to disable these bad configs.

You mention below the numbers are now at 17% of websites supporting DHE. Here's the numbers BEFORE they announced the exploit:

HTTPS DHE is commonly deployed on web servers. 68.3% of Alexa Top 1M sites support DHE, as do 23.9% of sites with browser-trusted certificates. Of the Top 1M sites that support DHE, 84% use a 1024-bit or smaller group, with 94% of these using one of five groups.

So I'd say they made the right choice, especially given that the browser makers still haven't fixed the browsers (possibly for compatibility reasons?). Remember, users have to upgrade browsers too, and while FF and Chrome get upgraded regularly for most people, IE really can't say the same thing.

So I'm quite happy to be sitting here in June with the numbers down significantly rather than waiting for Chrome FF and IE to release patches. Remember, the researchers believe this was ACTIVELY being exploited by the NSA before they released it.