TLS downgrade attack

Topic

New Reply

The Logjam (and Another) Vulnerability against Diffie-Hellman Key Exchange

Schneier on Security [blog]
May 21, 2015

“…. The Logjam attack allows a man-in-the-middle attacker to downgrade vulnerable TLS connections to 512-bit export-grade cryptography. This allows the attacker to read and modify any data passed over the connection. …

The attack affects any server that supports DHE_EXPORT ciphers, and affects all modern web browsers….

Much more interesting is the other vulnerability that the researchers found: Millions of HTTPS, SSH, and VPN servers all use the same prime numbers for Diffie-Hellman key exchange. … After this first step, an attacker can quickly break individual connections…. estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime…. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers. A close reading of published NSA leaks shows that the agency’s attacks on VPNs are consistent with having achieved such a break. …

Again, the NSA has put surveillance ahead of security. It never bothered to tell us that many of the “secure” encryption systems we were using were not secure. And we don’t know what other national intelligence agencies independently discovered and used this attack.

The good news is now that we know reusing prime numbers is a bad idea, we can stop doing it. …”

https://www.schneier.com/blog/archives/2015/05/the_logjam_and_.html

Reply | Quote

Replies

Latest versions of Chrome, Firefox, Safari and Android browsers are vulnerable, but Internet Explorer* is not: Security Attack Called Logjam makes Browsers Vulnerable

(* with Windows Update KB3061518 dated 05/12/2015 installed)

Reply | Quote

I am feeling irony here.

Reply | Quote

Latest versions of Chrome, Firefox, Safari and Android browsers are vulnerable, but latest Internet Explorer is not: Security Attack Called Logjam makes Browsers Vulnerable

Thanks Bruce. A comment on that link you provided led here. Do this for Mozilla engines and it should cease being vulnerable. PaleMoon users can do it on their own from their menu.
http://forums.mozillazine.org/viewtopic.php?p=14165963#p14165963

Addendum link for those running servers:
http://mohammadoweis.hubpages.com/hub/Another-SSL-major-flow-LOGJAM-attack

Reply | Quote

Not sure about Chrome but Firefox and Pale Moon can both be tweaked to block this vulnerability, see the comments on the URL in #2.

Reply | Quote

It might be better to get the Pale Moon details from the dev: https://forum.palemoon.org/viewtopic.php?f=1&t=8311

Reply | Quote

Little point in wondering, if people don’t upgrade their browsers to a version published specifically patched, or able to be patched, since this problem came to light, they’ll remain vulnerable.

Don’t forget, this is actually about outdated servers that are allowing weak and authentication. If all servers were patched, clients wouldn’t be vulnerable.

Reply | Quote

If you checkout some of the recent topics about users being unable to connect to servers because of authentication, you’ll find that in some cases action was pretty swift, just a few days.

Victim blaming or placing the burden on the victims isn’t something I condone; in every instance, users bumping into these issues, which aren’t difficult to check for, should always fire off emails to the server host and company owning the ‘secure’ site.

Reply | Quote

Derived from other posts/sites:

Test your browser: https://weakdh.org/

Test a server: https://community.qualys.com/message/29345#29345

Firefox based browser Add-on till Firefox 39.0 is released: https://addons.mozilla.org/en-US/firefox/addon/disable-dhe/

HTH

Reply | Quote

Firefox doesn’t need an add-on, you can do it yourself in about 2 minutes – first link in post #5.

cheers, Paul

Reply | Quote

Firefox doesn’t need an add-on, you can do it yourself in about 2 minutes – first link in post #5.

cheers, Paul

I quite agree Paul, and that procedure is well suited for the digerati.

The Add-on route, through a secure appearing URL (https://addons.mozilla.org), is for less experienced clients who become quite uncomfortable just after reading the next screen after going to about:config with its dire warning.

The Add-on route becomes the most attractive when considering deployment to a large client base or huge corporations.

Let’s agree that it’s good to have more than one viable solution. Yes?

Best wishes Paul.

Reply | Quote

Typical Windows, there’s always more than one way to skin a cat!

Reply | Quote

So, for Chrome Browser users, is there a fix until Chrome 45 goes mainstream (the only versions of Chrome in the Dev or Canary Channels thought not to be vulnerable now to Logjam exploits)?

In short, can the vulnerable SSL protocols be blacklisted as they can be in Firefox, through some sort of Chrome configuration tweak or switch in the launcher?

-- rc primak

Reply | Quote

According to this thread in Google groups, the answer is “sort of”…

https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/WyGIpevBV1s

Yeah, I read that too. I was hoping the protections supposedly already in Chrome Dev and Canary Channels (now at Chrome 45) could somehow be ported to Chrome 43 or 44 Beta, now. Chrome 45 isn’t supposed to be ready for general release for at least a couple of more weeks, even for the Beta Channel.

For Firefox, I have already made the adjustments to make the browser register at both testing sites as safe from this vulnerability. Nothing has broken online yet.

But I only run Firefox under Linux, and the Flash Player for Firefox in Linux is outdated and doesn’t play as well as the version in Chrome for Linux (44 Beta). So that’s the dilemma for me — go with a less secure browser for videos, and/or use Firefox for sensitive or secure sites and logins?

So far, none of my favorite sites make me choose security vs. functionality.

(Sidelight — the Spell Checker in The Lounge spells favorite as favourite. Interesting — are we British or Canadian in here now?)

-- rc primak

Reply | Quote

(Sidelight — the Spell Checker in The Lounge spells favorite as favourite. Interesting — are we British or Canadian in here now?)

That’s your browser, not the forum.

Reply | Quote

If I may add to this thread about Logjam, Chrome can be launched under Ubuntu Linux with restrictions on which cipher suites can (not) run:

Create a new Chrome Launcher Icon on the Unity Desktop. This can be done in any of the usual ways, so I won’t give lengthy paths to follow in your file system navigator app. Open with a right-click the desktop Launcher Icon for Chrome Browser, wherever it may be, and click on Properties. In the Command area, you can add a Blacklist switch:

–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

all in one single string. Then simply close the Properties window, and the change should stick. Test result at Weakdh.org. It worked for me, and my Chrome Beta v.40 [EDIT: Chrome 44.0] is now safe from Logjam according to the site.

This length of string, and even the syntax itself, don’t seem to work with Windows Chrome Browser.

For Windows users, a Compiled Batch File has been developed:
https://www.technoids.com/index.php/downloads/

The link to the public for download (at another site) has mysteriously disappeared. I had to register at this techie web site to get the batch file. (No personal info other
than a working email address is required to get the downloads from this site.) It does work, but Avast in Hardened Mode thinks it’s malicious. This is a false-positive, I believe.

This Batch File bans much more than just the vulnerable ciphers, and it comes in two degrees of restrictions. For most sites, the ChromeLocker Standard Batch File should not break the site, but should provide the needed protections. If you want to take a greater risk of breaking a site, there is also a Secure version. I recommend the Standard version. Test with your most sensitive sites before deploying on any mission-critical machines. Either version passes the Weakdh.org test.

-- rc primak

Reply | Quote

It worked for me, and my Chrome Beta v.40 is now safe from Logjam according to the site.

Does your “Chrome Beta v.40” mean it’s six months old, and you haven’t updated despite many fixes this year? Or did you mean Chrome Beta v.44?

Reply | Quote

Does your “Chrome Beta v.40” mean it’s six months old, and you haven’t updated despite many fixes this year? Or did you mean Chrome Beta v.44?

Typo.Chrome Beta 44.0, not 40. Thanks! I’ve inserted an EDIT into my original post up there.

-- rc primak

Reply | Quote

While we’re at it, I should update for what I had to do on my Transformer Book (Windows 8.1) tablet. The batch file doesn’t run there. (I don’t know why not.) And the existing Chrome desktop shortcut won’t accept the very long string of blacklisted cipher suites.

However, I finally found that I could right-click on an empty spot on the Legacy Desktop, and select to create a New Shortcut. The Wizard would accept the very long string of blacklisted cipher suites. So I created a Chrome Secure desktop shortcut, and pinned it also to my Metro Start Menu. For some reason, Windows 8.1 doesn’t know that this is a different shortcut from the normal Chrome Browser shortcut, so it won’t let me have both shortcuts pinned to the Taskbar. But otherwise, this method works, and it is only slightly more complicated than using the posted batch file in Windows 7.

Either the ChromeLocker batch file or the new Chrome Secure shortcut will pass muster at the Weakdh.org web site. This I tested on Windows 7 and Windows 8.1. (Linux doesn’t run Windows Batch Files natively, and doesn’t need to in this case.)

My tests show that even with all the latest updates, Microsoft’s Internet Explorer 11 is still not passing muster at the Weakdh test site. This despite claims in the media that Ie is secure against logjam attacks. Simply not true, in my tests.

SSL Locker from the same guy who wrote the ChromeLocker batch file, also does not secure IE 11 on my Windows 7 64-bits installation, and it won’t even run on Windows 8.1 32-bits on my Transformer Book tablet.

All of this will become a moot point when Google updates Chrome or Chrome Beta to be truly secure against logjam types of attacks. With only about 8% of web sites reporting breakage when the tighter security is imposed, I see no good reason not to include this protection in upcoming Chrome releases.

Am I wrong about this?

When Microsoft will really patch IE for this vulnerability, I don’t know. But I won’t take their word for it — they have lied already.

-- rc primak

Reply | Quote

Given that the browser manufacturers are happy to exclude all sorts for security issues, you adding a few more isn’t going to make any real difference. It may even encourage those web hosts to update their software.

cheers, Paul

Reply | Quote

Given that the browser manufacturers are happy to exclude all sorts for security issues, you adding a few more isn’t going to make any real difference. It may even encourage those web hosts to update their software.

cheers, Paul

That exact point is raised in this discussion thread about securing Chrome against Logjam attacks:
https://community.qualys.com/thread/15099

The thread also gives a bit of a response as to why we need to have different levels of cipher security.

Its the old security versus compatibility and ease of use problem. I could make 3 different versions [of SSL Locker or ChromeLocker batch files] called from a single menu. The whole idea is to keep it simple portable and functional so that users will actually use it. Geeks understand why they need it but the average joe who really needs to use it won’t use it all, if its too complicated or inconvienient.

I recently wrote this article [Warning: You may have to register with Technoids to read the whole article.] “Why do banks have weak HTTPS security implementations ?” and its hard enough to convince security analysts to make the necessary cipher changes on servers, let alone trying to explain to end users not to trust any HTTPS server and secure their browser to mitigate risk.

Further complicating implementation is the finding that on Windows 8/8.1 the SSL Locker batch file won’t run, and on Windows 7, I still find that the Weakdh test site finds the SSL Locker protected IE 11 insecure. So we’d have to keep updating and recoding to keep up with the changes in which ciphers are considered insecure, and the changes in how Operating Systems and security programs are handling the changes made by SSL Locker. Microsoft and others are no doubt going through this same difficult transition with their browser upgrades.

Ultimately, it’s up to the 8% or so of web sites which still use the insecure ciphers to upgrade on the server side and no longer accept this level of insecurity. Some visitors will get locked out and be told to upgrade their browsers or even their OS, as happens at banking sites when my Dad tries to log in with Windows ME and IE 5. A few diehards will refuse to upgrade, and they will lose privileges like online banking. Most customers will upgrade, and many will grumble but upgrade anyway. (Count me as a grumbler.)

But this is the balance in security — do we go for better security, or do we go for greater convenience and greater backwards compatibility? Like Heisenberg’s Uncertainty Principle, we unfortunately cannot have perfect security and perfect convenience and backwards compatibility, all at the same time.

-- rc primak

Reply | Quote

http://techdows.com/2015/05/how-to-make-firefox-browser-safe-against-logjam-attack.html

The above worked for me the post at the beginning of this #2 did not work for me .FF35 on XP

Securing Firefox browser against Logjam

1 . Visit About:config

2. Search for ‘ssl3′ and disable DHE_EXPORT ciphers by setting below preferences values to false.

security.ssl3.dhe_rsa_aes_128_sha
security.ssl3.dhe_rsa_aes_256_sha

3. Restart the browser, visit https://weakdh.org/ site, which should show the message ‘Good news! Your browser is safe against the logjam attack’.

If you’ve found difficult to to change about:config preferences, install Disable DHE add-on.

We’re expecting Mozilla to ship Firefox 39 final by disabling the above preferences.

Just because you don't know where you are going doesn't mean any road will get you there.

Reply | Quote