Https-everywhere: Securing targets on ports other than 80 and 443

[Bisaloo]

Type: other

I am starting to wonder if we should secure targets on ports other than 80 and 443 by default. This causes problems that are very hard to foresee.

See for example https://github.com/EFForg/https-everywhere/issues/14185 or https://github.com/EFForg/https-everywhere/pull/8969/commits/dc869513ff684124ff9666cb1b6e47b586371633.

What do you think?

[jeremyn]

The problem with this idea is illustrated by issue https://github.com/EFForg/https-everywhere/issues/1461 with the initial comment:

Have a look at this page:
https://www.sqlite.org/src/wiki?name=Bug+Reports

There is a link to:
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

As HTTS everywhere has sqlite.org in its database it will try to rewrite the URL. However this URL has a port number - and of course there can't be an HTTPS and an HTTP server on the same port at the same time. So the rewriting will cause the request to fail.

HTTPS Everywhere probably should not rewrite URLs with a port number (except when it knows that there is both an http and an https server on uncommon ports - but in that case it'd need to know which port the https one is, so this can only be whitelistet).

Rewriting http: to https: without ports works by default because the browser also knows to switch the port from 80 to 443. However rewriting a URL with a port number would not work because, as the quote above says, you can't run both an http and https server on the same port.

[jeremyn]

Or do you mean that we should by default exclude URLs with port numbers? In that case, yes we should, by the same logic.

[Bisaloo]

Oh, I did not see issue #1461. Basically, yes, I think we should prevent that. Blanket rule from="^http:" to="https:" should only apply to port 80 and 443.

If someone wants to secure a target on another port, they would need to write

    <rule from="^http://example.com:1337/"
            to="https://example.com:1338/" />

[Bisaloo]

If you think this is duplicate of #1461, feel free to close. I am keeping it open for now because #1461 focuses on an example while this issue is a broader reflexion on this question.

[jeremyn]

Thanks for clarifying. I don't think #1461 is a duplicate, I just used it as what I thought was a counter-example to your request.

[cschanaj]

It makes sense to me that trivial rewrites should be applied to the standard port only. I assume that a contributor commonly do not perform port scanning on each domain he/ she creating a ruleset for, and thus such rewrites are unintentional and untested. (AFAIK, Travis tests the implicit URLs over the standard ports only).

Given @jeremyn 's quotes, it is impossible to run HTTP and HTTPS on the same port. Trivial rewrites should not work on the URLs with fixed port number. So I agree to change the current behavior.

Since we are using RegExp to perform the rewrites, regardless of the port used in the URLs. We might need to do additional parsing and assertion in the runtime.

P.S. I am not sure about how downstream projects, like Brave and Cloudflare interpret the trivial rules. EFF might want to notify them after this change.

[bardiharborow]

it is impossible to run HTTP and HTTPS on the same port.

Well, not _impossible_, but highly, highly unlikely and just generally inadvisable.

Trivial rewrites should not work on the URLs with fixed port number.

We should keep rewriting an explicit :80 though, as some very broken websites use this in their HTML.

[wonderchook]

Should this discussion be summarized into documentation? Unless I'm missing something it seems to me that the solution is in the regex for the uncommon rulesets.

@cschanaj btw I tried to reach you by email can you let me know if you got it?

[jeremyn]

@wonderchook We could document this edge case but the fix has to be in code, that is, change the code so we don't rewrite ports other than 80/443 by default. From issue https://github.com/EFForg/https-everywhere/issues/14185 that @Bisaloo linked, having a target and regular rule for keyserver.ubuntu.com is enough to break behavior for http://keyserver.ubuntu.com:11371 . There's no reasonable way for a contributor to know there's an HTTP server listening on that unusual port so documentation wouldn't help much to avoid it.

[pipboy96]

I guess that in case a URL like http://example.com:80/ is encountered, :80 should be thrown away as tautological and the URL should be tested for possible rewrites as usual.

[onitake]

I'm hitting this issue with the "Encrypt All Sites Eligible" flag turned on.

A site that offers only HTTP and no HTTPS on a port other than 80 will cause HTTPS Everywhere to (correctly) display the "Insecure site" warning, but clicking one of the override buttons will still cause the URL to be rewritten to https, making the site inaccessible.