This site will have limited functionality while we undergo maintenance to improve your experience. If an article doesn't solve your issue and you want to ask a question, we have our support community waiting to help you at @FirefoxSupport on Twitter and/r/firefox on Reddit.

Avatar for Username

Search Support

Avoid support scams. We will never ask you to call or text a phone number or share personal information. Please report suspicious activity using the “Report Abuse” option.

Learn More

Este fío arquivouse. Faga unha nova pregunta se precisa axuda.

How to stop Firefox from redirecting me to https on my internal webserver

  • 5 respostas
  • 2 have this problem
  • 4 views
  • Last reply by McCoy

elowney
elowney
more options

So, this is different than all the other redirecting issues that I've read about so far.

The scenario:

I am an admin who has an internal, LAN-only webserver. It is serving up half a dozen web servers running on various ports for various reasons. E.g., Ticketing system on port 8080, an Apache-based Wiki on port 80, Nginx-based GitLab on 443 (the only https site!), etc. etc.

If I open the wiki and browse around, everything works great. If I open a new tab and go to Gitlab on 443, everything works great. However, as soon as I go back to the wiki and click a link (or just hit refresh), it takes me to the Gitlab error page, because it stuck an 's' on the http://webserver/wiki.php URL, and now Gitlab is trying to serve up an invalid URL at https://webserver/wiki.php.

Even though Gitlab is an internal webserver with a self-signed cert, the CA cert has been imported into Firefox so I get the green lock icon.

Troubleshooting / What doesn't work:

- The intranet page doesn't end in .dev or .foo, so it's not trying to load Google's website at that TLD. - Changing any settings in about:config doesn't help (at least none of the settings that can be found in the first few pages of a Google search). - Deleting my entire Firefox profile doesn't change anything - Running in Private Browsing / Purple screen doesn't change anything (when loading both websites in the same "mode" - see below). - I have checked the wiki webserver for any extraneous .htaccess files with URL redirects. - I have checked the wiki httpd.conf file(s) for any https redirects - There are no addons installed - Currently running version 60.2.2 ESR. I will try to upgrade to 60.4.0 ESR ASAP. This behavior does NOT happen with 52.x ESR.

What DOES work, albeit temporarily:

If I go into Preferences -> Clear History -> select the 'Site Preferences' setting, then the wiki will load and I can click around. However, the moment I go back to Gitlab and click on a link or refresh, the next URL I click on in the wiki will attempt to load a https version, Gitlab's webservice at port 443 takes over, and I get a 404. Go back to Preferences and delete the site preferences, and the cycle repeats.

This behavior also exists in Private Browsing mode with both sites either in two tabs or separate Private Browsing windows.

What works "permanently":

If I open the wiki in Regular Browsing mode and Gitlab in Private Browsing mode (or vice versa), I can access each website simultaneously in their respective windows. No https redirect occurs.

My conclusion:

As soon as I go to Gitlab, some Site Preferences setting gets saved that insists on redirecting all URLs at that domain to https. This site setting gets re-added at every web page invocation/reload, as demonstrated by deleting the Site Preferences and watching the behavior start up again on a refresh.

Site Preferences are shared among tabs in both Regular Browsing and Private Browsing, but they aren't shared BETWEEN Regular and Private browsing. This is immaterial to the issue at hand, just an interesting observation.

This problem started between versions 52 and 60.

I don't know how site preferences are saved. This could be a GitLab problem (generating these site preferences), but then why does v52 work fine...

So, this is different than all the other redirecting issues that I've read about so far. The scenario: I am an admin who has an internal, LAN-only webserver. It is serving up half a dozen web servers running on various ports for various reasons. E.g., Ticketing system on port 8080, an Apache-based Wiki on port 80, Nginx-based GitLab on 443 (the only https site!), etc. etc. If I open the wiki and browse around, everything works great. If I open a new tab and go to Gitlab on 443, everything works great. However, as soon as I go back to the wiki and click a link (or just hit refresh), it takes me to the Gitlab error page, because it stuck an 's' on the http://webserver/wiki.php URL, and now Gitlab is trying to serve up an invalid URL at https://webserver/wiki.php. Even though Gitlab is an internal webserver with a self-signed cert, the CA cert has been imported into Firefox so I get the green lock icon. Troubleshooting / What doesn't work: - The intranet page doesn't end in .dev or .foo, so it's not trying to load Google's website at that TLD. - Changing any settings in about:config doesn't help (at least none of the settings that can be found in the first few pages of a Google search). - Deleting my entire Firefox profile doesn't change anything - Running in Private Browsing / Purple screen doesn't change anything (when loading both websites in the same "mode" - see below). - I have checked the wiki webserver for any extraneous .htaccess files with URL redirects. - I have checked the wiki httpd.conf file(s) for any https redirects - There are no addons installed - Currently running version 60.2.2 ESR. I will try to upgrade to 60.4.0 ESR ASAP. This behavior does NOT happen with 52.x ESR. What DOES work, albeit temporarily: If I go into Preferences -> Clear History -> select the 'Site Preferences' setting, then the wiki will load and I can click around. However, the moment I go back to Gitlab and click on a link or refresh, the next URL I click on in the wiki will attempt to load a https version, Gitlab's webservice at port 443 takes over, and I get a 404. Go back to Preferences and delete the site preferences, and the cycle repeats. This behavior also exists in Private Browsing mode with both sites either in two tabs or separate Private Browsing windows. What works "permanently": If I open the wiki in Regular Browsing mode and Gitlab in Private Browsing mode (or vice versa), I can access each website simultaneously in their respective windows. No https redirect occurs. My conclusion: As soon as I go to Gitlab, some Site Preferences setting gets saved that insists on redirecting all URLs at that domain to https. This site setting gets re-added at every web page invocation/reload, as demonstrated by deleting the Site Preferences and watching the behavior start up again on a refresh. Site Preferences are shared among tabs in both Regular Browsing and Private Browsing, but they aren't shared BETWEEN Regular and Private browsing. This is immaterial to the issue at hand, just an interesting observation. This problem started between versions 52 and 60. I don't know how site preferences are saved. This could be a GitLab problem (generating these site preferences), but then why does v52 work fine...

Chosen solution

Okay, this is not as crazy as it sounds:

elowney said

As soon as I go to Gitlab, some Site Preferences setting gets saved that insists on redirecting all URLs at that domain to https. This site setting gets re-added at every web page invocation/reload, as demonstrated by deleting the Site Preferences and watching the behavior start up again on a refresh.

The Gitlab webapp sends an HTTP Strict Transport Security header to Firefox, which Firefox caches and applies to everything on the same host (regardless of port). When the header is sent to Firefox in a private window, it is not stored persistently for purposes of regular windows. (And based on your experience, vice versa, although I'm not sure that is reliable.)

Note: The relevant data file in your profile is SiteSecurityServiceState.txt

There's a workaround listed here: https://docs.gitlab.com/omnibus/settings/nginx.html#setting-http-strict-transport-security

Ler a resposta no contexto 👍 2

All Replies (5)

WestEnd
WestEnd
more options

It could be how the security checks are changed how they are handled with the newer Browser thus causing the redirect to happen.

cor-el
cor-el
  • Moderator
  • Top 10 Contributor
more options

Some domains have been added to the preload HSTS list.

You can no longer use some domains like .dev locally because its owner (Google) has added this domain to the HSTS preload list and a secure connection is automatically enforced. The ".dev" domain landed on the HSTS preload list in Firefox 59.0b7 and this means that Firefox will automatically try a secure connection to these TLDs.

A possible workaround is to disable the HSTS preload list temporarily, but this is not recommended.

jscher2000 - Support Volunteer
jscher2000 - Support Volunteer
  • Top 25 Contributor
more options

Chosen Solution

Okay, this is not as crazy as it sounds:

elowney said

As soon as I go to Gitlab, some Site Preferences setting gets saved that insists on redirecting all URLs at that domain to https. This site setting gets re-added at every web page invocation/reload, as demonstrated by deleting the Site Preferences and watching the behavior start up again on a refresh.

The Gitlab webapp sends an HTTP Strict Transport Security header to Firefox, which Firefox caches and applies to everything on the same host (regardless of port). When the header is sent to Firefox in a private window, it is not stored persistently for purposes of regular windows. (And based on your experience, vice versa, although I'm not sure that is reliable.)

Note: The relevant data file in your profile is SiteSecurityServiceState.txt

There's a workaround listed here: https://docs.gitlab.com/omnibus/settings/nginx.html#setting-http-strict-transport-security

elowney
elowney Question owner
more options

jscher2000 said

There's a workaround listed here: https://docs.gitlab.com/omnibus/settings/nginx.html#setting-http-strict-transport-security

That was it! Thank you so much. I had browsed that very document earlier, but skipped the HSTS section as I was not familiar with that protocol. Setting hsts to 0 and reconfiguring did the trick.

McCoy
McCoy
more options

Hello elowney,

Would you be so kind as to mark jscher2000's post as Chosen Solution instead of "Helpful"  ? ("Solved the problem" button to the right of that post)

Thank you in advance  !