search

EFForg / https-everywhere

A browser extension that encrypts your communications with many websites that offer HTTPS but still allow unencrypted connections.
https://eff.org/https-everywhere
Other
3.37k stars 1.09k forks source link

Extension is broken/corrupted and won't repair on Chrome #5874

Closed faried closed 8 years ago

faried commented 8 years ago

I see the problem both on Mac OS 10.11.6 with Chrome 54.0.2810.2 and on Ubuntu 14.04. The fact that it "broke" and I didn't notice it immediately seems like comp.risks fodder.

screen shot 2016-07-30 at 10 36 23
auyongcheemeng commented 8 years ago

Ditto on the the problem on Chrome 54.0.2810.2 (64 bit) on Win10.

Hainish commented 8 years ago

I can reproduce this, looks like it's fairly platform-independent, happening with Chrome 54 across the board. @semenko any idea what may be going on here?

semenko commented 8 years ago

Hm, IIRC that failure results when a local checksum/signature of the extension contents doesn't match the signature of what was submitted to the Chrome app store. (The intent is to prevent malware from modifying extension scripts.)

I've yet to see this personally -- and I don't have a great idea of what could be causing it.

If this weren't platform independent, I'd guess some client-side antivirus was rewriting / removing some of our package data [e.g. for a "suspicious" url].

Hainish commented 8 years ago

Thanks @semenko. Looks like this is happening with our Privacy Badger extension on Chrome 54 as well. This may be some extra contents that are packaged but not checked on either the client-side or Chrome Web Store side. I'll have to consider how to debug this, though - seems tricky, and I don't see any debugging output. I wonder if we have contacts at CWS that can help?

semenko commented 8 years ago

Very odd -- maybe there's a strange character encoding / odd file making it's way in, and that's hitting an edge case in Chrome?

I don't see this in 54.0.2816.0 (Ubuntu). And I don't see any similar bugs at https://crbug.com/

Hainish commented 8 years ago

cc @cooperq - is there a similar issue for Privacy Badger you can link to?

faried commented 8 years ago

I'm not sure what caused it, but it seems fixed now. Maybe a transient issue with Chrome dev? I'm on 54.0.2816.4 on OS X and 54.0.2816.0 on Linux now.

I ran into the Privacy Badger issue on Linux at the same time, but not on OS X.

Hainish commented 8 years ago

@faried I'm still seeing it on Ubuntu w/ Chrome 54.0.2816.0 (64-bit)

Hainish commented 8 years ago

In 54.0.2824.0 dev-m (64-bit) on Windows 10, HTTPSE successfully installs.

I'm still getting a failure to install for 54.0.2824.0 dev (64-bit) on Ubuntu.

cooperq commented 8 years ago

Relevant privacy badger issue: https://github.com/EFForg/privacybadgerchrome/issues/843

semenko commented 8 years ago

My instinct is that this is an edge case / error with the custom key/signing process, which isn't used very commonly with extensions.

(the 'key' parameter in manifest.json / https://developer.chrome.com/extensions/packaging )

cooperq commented 8 years ago

@semenko this is my instinct as well. I suspect we should talk to someone at google about this.

Hainish commented 8 years ago

If this issue is disappearing from a point upgrade, as reported above, they may well know about it and have fixed it already. I wouldn't count on it, though - I still see it for the latest Linux Chrome dev 54.0.2824.0. I'm with @semenko and @cooperq on this, probably best to find someone on the Chrome side to help us debug this.

cooperq commented 8 years ago

For me it has been around for a while, so I doubt it will go away on a point upgrade.

faried commented 8 years ago

It worked for a couple of weeks for me, but today I noticed that with 54.0.2837.0 dev (on OS X), it's broken again.

cooperq commented 8 years ago

We have a fix for this now which will be in the next release. For now you can go to chrome://flags and find the setting for 'extension content verification' and change it from 'enforce strict' to 'enforce'. You then can uninstall and reinstall the extension and it should be fixed. Once the fix is released you should be able to change it back.

jeremyn commented 8 years ago

Just a note: I separately reproduced with this @jmauss in issue #6696 using Chrome version 53.0.2785.89 m (64-bit) on Windows 10.

Hainish commented 8 years ago

Duplicating the comment from that thread:

This should be fixed as of d45ccb1, but we'll have to do a release to make sure the fix worked. I'll try to make a release today. If I'm not able to make a release, I'll have to hold off until Monday

jeremyn commented 8 years ago

Also to @cooperq 's comment: I can't get the extension to work/not show corrupted using any of the four options for the Extension Content Verification flag, reinstalling the extension after each change, so that's not a good workaround for me. (I can wait, I'm just reporting my findings.)

Hainish commented 8 years ago

Can anyone confirm this error is gone in 2016.9.1?

On August 31, 2016 2:48:09 PM PDT, Cooper Quintin notifications@github.com wrote:

This will be fixed by the next release

You are receiving this because you were assigned. Reply to this email directly or view it on GitHub: https://github.com/EFForg/https-everywhere/issues/5874#issuecomment-243913130

Sent from my Android device with K-9 Mail. Please excuse my brevity.

faried commented 8 years ago

2016.9.1 works for me on 54.0.2840.8 dev (OS X). I had to uninstall and reinstall the extension -- updating to 2016.9.1 didn't work.

fuglede commented 8 years ago

The issue has also been rereported on the mailing list.

jeremyn commented 8 years ago

Still broken for me, even after uninstalling/reinstalling.

Hainish commented 8 years ago

What a heisenbug - at first I was getting it consistently with chrome-dev on Windows 10, now I can't seem to reproduce it :anger:

faried commented 8 years ago

Tried it on my home desktop (Ubuntu 14.04, Chrome 54.0.2840.8), and both HTTPS Everywhere and Privacy Badger are marked corrupted. Reinstalling doesn't help. This is bizarre.

CirnoT commented 8 years ago

I can confirm this issue hit me on Chrome Stable 53.0.2785.89 m, Windows 10 Pro x64. Restarting Chrome fixed the issue for now. The issue showed up by itself after i woke up - Chrome was opened all night.

Hainish commented 8 years ago

I've opened a bug report with Chrome, but apparently since I marked it as a security issue it is not publicly viewable (otherwise I would link to it here)

Lloth commented 8 years ago

Same issue here - recently upgrading to 53.0.2785.89 m (64-bit) - Oddly the plugin was for sure working yesterday. Perhaps related to the recent plugin update? (Version: 2016.9.1)

Also effecting 55.0.2846.4 canary (64-bit) Reinstalled from store and repair and both have the same issue.

Disabling the hash enforcement DOES work.

jeremyn commented 8 years ago

@Hainish I tagged this High Priority, maybe it'll jump out at people looking to report it and we can prevent some duplicate issues.

Hainish commented 8 years ago

Thanks @jeremyn

jeremyn commented 8 years ago

@Hainish Sure. You could also add a note to https://www.eff.org/https-everywhere if you think that's appropriate.

funkydude commented 8 years ago

Chrome 53 is now released and this is broken for everyone. The title should be renamed to remove the mention of "dev". You might also want to get on fixing this since the extension has now been rendered useless for all Chrome users.

jeremyn commented 8 years ago

@funkydude I've updated the issue title. I agree this is serious. @Hainish opened a bug with Chrome yesterday (see this comment).

Deadroom commented 8 years ago

I had to clean Chrome cache, disable all extensions and add one by one again to make sure none of them were breaking it. When i reinstalled the extension it gave me no problem anymore. Using Chrome 53.0.2785.92 (64-bit) on Linux.

war59312 commented 8 years ago

I was able to fix it by visiting the extensions page on the chrome web store - there was a message at the top of the screen saying the extension was disabled and there was a link to re-enable it.

I found that this was also happened with HTTPS Everywhere.

Confirmed. Same workaround as thrnz above. Thanks. And indeed works with Privacy Badger too.

Even on Chrome Dev. See related: https://github.com/EFForg/privacybadgerchrome/issues/911

jeremyn commented 8 years ago

I can also confirm the fix. To be super specific, you need to:

  1. install the 2016.9.1 update, and
  2. go to the HTTPS Everywhere page in the Chrome Web Store, and
  3. click the Enable link you see appear in a orange/yellow bar at the top of the page.

I guess there is some problem in Chrome where once the extension is disabled as corrupted, you have to manually re-enable it, even if you fix the corrupted extension. It'll be interesting to hear from the Chrome team.

EDIT: thanks to @thrnz for finding the fix, and @war59312 for linking it here.

fuzzyroddis commented 8 years ago

Occurring on Version 53.0.2785.89 (64-bit) on OS X with no AV

chrome://extensions/ gives me the option to repair but I haven't tried it.

Privacy Badger hasn't been affected, yet. Even though I've pressed update extensions.

fuzzyroddis commented 8 years ago

@Hainish could you link the issue in here?

ghost commented 8 years ago

For all those having issues with the latest version showing as corrupt, try these steps:

  1. Install extension.
  2. Once it shows "This extension may have been corrupted", go back to the Chrome store and open up this extension's page (https://chrome.google.com/webstore/detail/https-everywhere/gcbommkclmclpchllfjekcdonpmejbdp).
  3. The top of the page will have this text -- "This item has been disabled in Chrome. Enable this item". Click it.
  4. Extension will get activated! See this : cats
anand-bhat commented 8 years ago

I've posted similar instructions in the Chrome webstore earlier today as I saw quite a few reports there.

jeremyn commented 8 years ago

Good idea @anand-bhat , thanks!

lucaspetter commented 8 years ago

This issue is showing up for me on one computer that has Chrome 53.0.2785.89, but not on another computer with 52.0.2743.116.

I tried @jeremyn's and @ChamZank's fix but it still doesn't work. When I click "Enable this item" on the Chrome web store, the HTTPSE icon briefly appears in the browser toolbar, but it disappears a second or two later. The Chrome web store page reloads and still says "This item has been disabled in Chrome. Enable this item." Also, in chrome://extensions/, it still says "This extension may have been corrupted." Clicking "Enable this item" again produces the same results.

Hainish commented 8 years ago

@fuzzyroddis as I've stated above, it won't do you any good, since the issue is only visible to the Chromium security team. But here it is: https://bugs.chromium.org/p/chromium/issues/detail?id=643814

jeremyn commented 8 years ago

@lucaspetter Previous reports are that the problem appears with the 53.0.2785.89 stable version of Chrome, so it makes sense that that's where you started to see it. Can you confirm that you are using the 2016.9.1 version of the extension? If necessary, uninstall and reinstall the extension to be sure.

lucaspetter commented 8 years ago

@jeremyn Yes, both computers have version 2016.9.1. I tried uninstalling and re-installing HTTPSE, as well as restarting Chrome and then re-installing, but the issue still remains.

fuzzyroddis commented 8 years ago

@Hainish Thanks, there is a public issue here: https://bugs.chromium.org/p/chromium/issues/detail?id=643931

Chrome's team marked it as WontFix... sigh

I wonder if their version number checking is buggy?

Hainish commented 8 years ago

This has been acknowledged by the Chrome security team as a bug on their end in the way that Chrome does Extension Content Verification when extensions are signed with special security measures in place, as we have for our EFF extensions. Chrome is currently working on a fix to this, which involves both their Web Store and the core Chromium codebase.

They are also looking into ways in which users will have HTTPS Everywhere re-enabled automatically if it has been disabled by Extension Content Verification.

We are working with their team in ensuring that the fixes are released as quickly as possible, and will keep you informed as we make progress on this issue.

lucaspetter commented 8 years ago

@Hainish

... when extensions are signed with special security measures in place, as we have for our EFF extensions.

What are these special security measures regarding extension signatures? Can you discuss them while the Chromium security issue is still open?

Thanks for keeping us updated!

Hainish commented 8 years ago

@lucaspetter we don't want Google to have a copy of the private key that we use to sign our extensions. Usually, when you create an extension with the Web Store, it assigns a private key to you. That would make it so that Google could, hypothetically, publish malicious update to our extensions. To avoid this problem, we've generated a private key ourselves, and have a signing process that differs from most extensions. We sign the extension with our own private key before uploading it to the Web Store, which is then able to publish it.

fuglede commented 8 years ago

I understand where you are coming from, but really, as long as we are speaking Chrome and the Web Store specifically, they can publish malicious updates if they want to; I doubt that anybody is checking the signatures by hand (if that's even possible?)