Https-everywhere: "Block all HTTP requests" blocks requests even to localhost

Created on 26 Jul 2015 · 6Comments · Source: EFForg/https-everywhere

Localhost refers to the 127.0.0.1 loopback interface, therefore no data is ever leaving the network. Including it in the "block all HTTP requests" makes it needlessly harder to interact with local webservers.

Source

adammw

Most helpful comment

Ok, rethinking this, I like it. I'll try to integrate it, at least in Chrome, with the overhaul of the extension.

Chrome trusts these origins, which we should whitelist (if we see them in webRequest):

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

per https://www.chromium.org/Home/chromium-security/security-faq#TOC-Which-origins-are-secure-

semenko on 27 Dec 2015

👍3 ❤1

All 6 comments

Going to close as wontfix for now.

Feel free to send a PR to fix, but this adds a fair amount of complexity if we try to deal with localhost 127.0.0.0/8 resolution, etc.

semenko on 17 Dec 2015

What about an HTTP-OK whitelist? That would resolve this without it being a special case fix.

mweitzel on 25 Dec 2015

Ok, rethinking this, I like it. I'll try to integrate it, at least in Chrome, with the overhaul of the extension.

Chrome trusts these origins, which we should whitelist (if we see them in webRequest):

(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)

per https://www.chromium.org/Home/chromium-security/security-faq#TOC-Which-origins-are-secure-

semenko on 27 Dec 2015

👍3 ❤1

@Hainish, what's the status of this after https://github.com/EFForg/https-everywhere/commit/1dafcc9578ab3c9287dc4f811878269fdd57f9ae?

Bisaloo on 4 Mar 2017

I've closed issues #9142 and #13511 as duplicates of this issue, though those issues are about allowing unencrypted requests to RFC1918 private addresses and not localhost 127.0.0.1/8. If a fix for this issue is limited to just localhost, then one of those issues should be reopened or a new issue should be created to cover other private address ranges.