Https-everywhere: Blocking non-encrypted traffic not working in FF

[foobar13373]

I just got Version "2017.8.15" in FF55 (64Bit) on Win10 and the checkbox to block all non-encrypted traffic does not work at all. It does not get saved and no http-content is blocked.

Also, how can I enable/disable rules with this new interface?

[HTTPSNowhere]

Duplicate https://github.com/EFForg/https-everywhere/issues/10150

[aemixdp]

Exactly the same issue in Chrome. It worked perfect few days ago.

[gripedthumbtacks]

i can also confirm this issue on chrome. very strange

[Hainish]

I'm not experiencing this behavior on Firefox 55 or the latest Chromium. Are you still seeing this on >= 2017.8.17?

[foobar13373]

@Hainish
With your latest changes regarding the localStorage, this is also working for me in the currently running browser session. This means:

The checkbox state is saved between browser starts, but the functionality only works if one dis- and re-enables the checkbox after a browser restart (which comes from clearing the storage on exit, I assume).

[ansell]

I was seeing unencrypted requests succeeding with 2017.8.19 on Firefox-55.0.2 until I unchecked, and then came back and checked the setting again. Before doing that, the icon was also not red, as it was previously, but after that process, it is red again.

[Hainish]

@foobar13373 glad to hear the latest changes fixed this issue, unless I'm misunderstanding. Feel free to close if this is no longer an issue.

[ivan-kolmychek]

@Hainish I think you've missed this part

but the functionality only works if one dis- and re-enables the checkbox after a browser restart (which comes from clearing the storage on exit, I assume).

which is not how addon was working before for me - the flag, icon state and functionality state were consistently being saved and restored after I've closed browser and opened it again.

It would be really cool if you can not worry about re-enabling it every time you open the browser. :)

Can we get that behavior back again? Is it blocked by something?

[gripedthumbtacks]

right, this is actually now a SECURITY ISSUE. for instance, you close your browser on a secure network, then move to another network that is hostile, open the saved browser and all your traffic and cookies potentially leak over HTTP without protection. same bug also confirmed in chrome version of extension

[gripedthumbtacks]

opened #12190 to track wider issue

[gripedthumbtacks]

could potentially fix this security bug by simply changing

pref("extensions.https_everywhere.http_nowhere.enabled", false);

to

pref("extensions.https_everywhere.http_nowhere.enabled", true);

in

src/defaults/preferences/preferences.js

and making it more secure by default, requiring users to downgrade to the less secure option if they choose

[Hainish]

Can someone give me specific steps to reproduce this error? The description given is not reproducing this for me, but it may be that I'm not following the exact same workflow.

[Hainish]

@DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K this will not work. The WebExtension has no access to the old preferences that the legacy XPCOM extension drew from.

[gripedthumbtacks]

This issue started about two weeks ago in both Firefox and chrome. To reproduce, here are some potential steps.

Install extension

Enable no http mode

Close browser

Reopen browser. Notice that the setting is disabled (icon is blue), even if the option appears enabled. Enabled icon color is red when one.

Try chrome as well.

[ghost]

Can reproduce. It becomes red for a split second before being changed to blue. Something seems to disable HTTPS-only mode.

[ansell]

I am seeing the same behaviour as @DtpEJsaYXDU4GDH8dE4MyI9VrieF0UZpPZ0K76K My workaround above of disabling and re-enabling doesn't seem to be persisted across Firefox executions. When starting up Firefox, the icon is blue (I haven't noticed it flickering from red to blue myself), but the checkbox beside "Block all unencrypted requests" is checked, which matches the expected preference since it was checked on the previous Firefox execution.

[jimmycuadra]

I have been experiencing the exact same behavior described by @ansell in Chrome.

[Bisaloo]

I was waiting to hear more on this issue but this looks like an exact duplicate of https://github.com/EFForg/https-everywhere/issues/10478.

[Hainish]

This behavior is not observed in Firefox 52.3.0 but interestingly is observed in 55.0.1. Possible Firefox regression? Looking into this further now.

[gripedthumbtacks]

Doubt it could only be a regression in firefox if this issue ALSO affects chrome.

[Hainish]

This stems from a race condition between the setting of the storage object in https://github.com/EFForg/https-everywhere/blob/04b4e1df08543be683655c67652b8d337d61daf7/chromium/storage.js#L5 and the retrieval of background.js stored global variables in https://github.com/EFForg/https-everywhere/blob/04b4e1df08543be683655c67652b8d337d61daf7/chromium/background.js#L70-L79. https://github.com/EFForg/https-everywhere/pull/12268 fixes this.

[Hainish]

I can make a release tomorrow with this change.

[ivan-kolmychek]

Works for me now, thank you @Hainish.

[matryoshkababushka]

It's good to update release in FF addons now. Who does that, by the way?

[ghost]

@CrackHD @Hainish does.