search

Rob--W / https-by-default

Use HTTPS by default for navigations from the location bar in Chrome / Firefox.
MIT License
63 stars 12 forks source link

unwanted use of https when URL modified #16

Closed bugfood closed 6 years ago

bugfood commented 6 years ago

Hi,

Thanks for this extension. I've been using it for a while, and there is one use case that is broken for me: modifying the URL in http-only tabs.

Steps to reproduce:

  1. Go to an http URL, e.g. http://example.com/1
  2. Modify the URL in the URL bar, e.g. http://example.com/2
  3. Hit

Expected results: Firefox goes to the http URL as directed, e.g. http://example.com/2

Observed results: Firefox goes to an https URL, e.g. https://example.com/2

If instead I open a new tab and enter the http URL, that works fine--but modification in place does not.

I'm running Firefox 57 with HTTPS by default 0.4.2 on Debian Sid.

Thanks, Corey

Rob--W commented 6 years ago

What is the extent of the URL modification?

In Firefox 57+ an extension cannot see the difference between the user typing a URL with or without an explicit "http:" prefix, so I use heuristics to guess the most likely scenario based on the lifetime of the tab, when it was last activated and the URL of the current page in the tab.

I could add a rule to not redirect URLs if the currently shown page is http and the domains are equal. But that would not catch http://a.example.com/path -> http://b.example.com/path.

What is your use case? Would the following rule solve this issue for you? "do not redirect to https if the current URL's domain is the same as the "typed" URL's domain".

bugfood commented 6 years ago

Thanks for your explanation. That sounds a bit tricky...

The use case I was thinking of when I wrote the above was for navigation within a single domain by altering the path or query parameters (sometimes that's just quicker than navigating within the site, or sometimes I need to test something).

Another use case is modifying the least-significant part of the domain in order to test individual servers in a cluster, e.g. test http://web01.example.com/ and then modify the URL to test http://web02.example.com.

The rule you described, as I understand it, would fix the first use case but not the second. It would be an improvement, though. I don't know how much you can do without being able to determine the user-supplied scheme in the URL--there's always going to be a corner case like somebody running the same site on different domains and wanting to test each in turn. That seems like a silly limitation on Firefox's part.

My expectation of https-by-default browser behavior is to only use https if I have not supplied a scheme in the URL. Aside from that, I wouldn't really mind being redirected to https if the target site actually worked on https, but in many cases the target site is http-only.

The way I ran into problems was the following:

  1. Browse an internal http site that worked fine.
  2. Modify the URL.
  3. Get a connection refused, check my VPN, troubleshoot the target server, and eventually realize I was inadvertently trying https.

Is it possible to detect network-level errors after redirecting to https? I suppose auto-whitelisting based on network errors is a bad idea due to MITM attacks, but maybe prompting the user in that case would be an ok stop-gap.

Thanks, Corey

Rob--W commented 6 years ago

I have published a new version, with the following logic:

Is it possible to detect network-level errors after redirecting to https? I suppose auto-whitelisting based on network errors is a bad idea due to MITM attacks, but maybe prompting the user in that case would be an ok stop-gap.

I am currently not planning to do that, since a network error is not the only effect of an undesired navigation. Sometimes the server redirects to a completely different site. The http->https upgrade logic should be sound. If you encounter a situation where the logic is broken, please open a new issue.