Open Bug 1341099 Opened 8 years ago Updated 3 years ago

Unwanted auto http:// to https:// redirect

Categories

(Core :: Security Block-lists, Allow-lists, and other State, defect)

51 Branch
Unspecified
macOS
defect

Tracking

()

People

(Reporter: mavis, Unassigned)

Details

Hello hello! It seems like if you have visited a site on https, in the future when you visit the same site using http Firefox auto directs you to https. This behaviour is great for most cases. However, if you are a dev who's developing something locally, sometimes you need to test things with and without SSL. This auto redirect feature then becomes a problem and there doesn't seem to be an easy to turn it off. After searching on the Web for a while I found this solution: http://riaschissl.bestsolution.at/2014/03/unwanted-http-to-https-rewrites-in-firefox/ . This solution requires user to go to History, find the site, and "Forget about this site". This resolves the problem but at the same time it feels a bit like a hack to me as "Forget about this site" seems to just erase(or hide) that site from History. I wonder if we can have an option on Firefox Preference's Security section to let users decide whether or not they want this auto redirect to happen? Thanks!
If you open the settings of the developer tools and check 'Disable HTTP cache (when toolbox is open)', does it ignore the remembered redirect?
Flags: needinfo?(mavis)
if you type the whole schema in the locationbar (so you type http://...) we won't do any kind of "redirects" from there. If instead what you see happens at a lower level (netwerk) this should probably go in a different component.

This is a new version of FF-Dev but the report aptly describes what I have witnessed.
I use Firefox Developer Edition as my browser of choice for development.
My current setup uses http accessing an application under development in a Vagrant box(Virtualbox).
I can access the application using an http-url.
Clicking a link in the application, which is http://..... results in an automatic unwanted http-to-https-redirect.
Since the webserver is not on port 443 ATM the page cannot be accessed.
There is no redirect(location-header) in place to explain this behavior .
Subsequent visits to any path on that domain will result in a redirect.
To get rid of this behavior, I will need to clear all the caches and history, causing me to loose sessions and history.
This makes the browser virtually unusable for my purposes because of the impractical implications, always purging cache,history, etc.
Opening dev-tools appear to provide a quick workaround, but since this is the Developer-edition and the user ought to have the last word on how an application runs, I feel that a switch to globally and definitely turn of this behavior is warranted.

Also note that explicitly writing the schema (http://) or disabling the strict https-mode is not preventing this behavior from occurring.

Details
Mac Catalina (10.15.6)
FF-Dev 89.0b4 (64-bit)
URL was mapped to a private address-space(IPv4)

Cheers

Update:
Dev-Tools are not fixing the problem reliably.

Sorry for triple posting, but I cannot find the edit button.
Further investigation yielded a DNS HSTS configuration for the main domain to be at fault here.
Unfortunately setup makes the local domain a subdomain of the main side(don't ask, I know it is daft).
So while the about:config option for disabling HSTS is still outstanding in the whole works as designed.
I wouldn't expect the explicitly mentioned schema to override HSTS.

Hi alst20, I'm having trouble parsing comment 5.

It sounds like you were able to determine that HSTS was at fault for the unwanted redirection, and it also sounds that if you disable HSTS in about:config, you can do what you need.

Can you please write a new comment describing:

  1. The steps to reproduce the issue you're seeing
  2. The expected outcome
  3. The actual outcome

That'll make it easier for us to determine how to proceed here.

Also clearing the ~4yr old needinfo on mavis.

Flags: needinfo?(mavis) → needinfo?(alst20)

Hi Mike,

thanks for the prompt response.

  1. Have a domain foo.bar configuring HSTS for all subdomains. have dev.foo.bar be a local VM or container accessed via HTTP . Initial usage will result in the local setup being accessible and usable. After a while you will experience an unexpected redirect to HTTPS. Subsequent attempts to access the local setup via HTTP will fail from here on out.
  2. Once it was clear that HSTS was in play, configured via the prod-domain, the behavior became obvious and it is also a behavior I would expect in a setting like this.
  3. s.a.

A pointer to the cause of the redirect, or an easy way to exclude specific domains, in this example dev.foo.bar, from using HSTS if an HSTS configuration was not specifically issued for this domain(read the HSTS configuration needs to be set for this domain and not via sub-domain configuration from the parent domain) would be nice. Yet, this scenario will most likely only pop up in settings involving developers with this developers being able to easily change domains of their local environments. As I said, I was surprised by this because I was unaware of the HSTS-configuration in the parent domain.

Flags: needinfo?(alst20)

Okay, given comment 7, I'm not sure this belongs in Firefox :: Preferences. This might be a WONTFIX, but I really don't know. I'm going to see if the people who manage HSTS have opinions by putting this in Core :: Security Block-lists etc

Component: Preferences → Security Block-lists, Allow-lists, and other State
Product: Firefox → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.