17

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?

  • 2
    Apparently, there's no fix yet, which is kind of odd especially for Chromium. – edmz May 25 '15 at 15:40
  • @black Odd indeed. It has been more than a month now and neither Chrome nor IE have fixed this bug. – curious_cat Jun 24 '15 at 18:11
  • Chromium 43.0.2357.130, recently rolled out, is no longer vulnerable. – edmz Jun 24 '15 at 18:54
  • 4
    @black I am using Version 43.0.2357.130 m. Yet the website "weakdh.org" reports that "Warning! Your web browser is vulnerable to Logjam and can be tricked into using weak encryption. You should update your browser." Are you sure it was fixed? – curious_cat Jun 25 '15 at 3:10
15

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:

(See also: Wikipedia: Logjam)

Some DH key lengths to test are here:

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.)

  • 20150906: Chrome 45.0.2454.85 m rejects dh512.badssl.com with ERR_SSL_WEAK_SERVER_EPHEMERAL_DH_KEY – smooth reggae Sep 6 '15 at 11:39
  • Yup. See edit at very top. Post is kinda messy. – StackzOfZtuff Sep 6 '15 at 12:26
5

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.

  • They can't have it both ways though. i.e. The site weakdh.org reports that 17% of the top million sites are vulnerable. That sounds like a lot of servers that can potentially be attacked. In addition to fixing servers the surest fix seems at the browser client end. Why not refuse to downgrade to any of the weak protocols. At least allow the user such an option. If sites break, administrators will fix them. – curious_cat Jun 24 '15 at 1:50
  • 1
    @curious_cat See the edited response above addressing the numbers you quoted from weakdh.org – Steve Sether Jun 24 '15 at 3:24
  • Client needn't offer DHE-EXPORT suites, and modern browsers don't; the attack tampers both Hello's and subsequently covers by forging Finished. And server needn't accept DHE-EXPORT if it uses a too-small group for normal DHE, which bad code or configuration can do (and the researchers found some that did). In particular, server in Java through 7 (which was still current in 2015Q2, and undoubtedly still used even though formally obsolete) never uses DHE larger than 768, which the researchers estimate (very roughly) as "feasible with academic power". – dave_thompson_085 Sep 3 '15 at 11:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.