X
Tap here to go to the mobile version of the site.

Safely share files online with encrypted links that “self-destruct.” Try Firefox Send.

Give hackers a swift kick in the cookies. See if your data has been affected by a breach with Firefox Monitor. Try it now.

Access your history, passwords and open tabs wherever you are with Sync. Connect a second device.

Support Forum

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

Posted

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

Read this answer in context 2
Quote

Additional System Details

Application

  • User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

More Information

WestEnd
  • Top 10 Contributor
59 solutions 4805 answers

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

It could be how the security checks are changed how they are handled with the newer Browser thus causing the redirect to happen.
Was this helpful to you? 1
Quote
cor-el
  • Top 10 Contributor
  • Moderator
16922 solutions 152808 answers

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.

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. *network.stricttransportsecurity.preloadlist = false *[https://medium.engineering/use-a-dev-domain-not-anymore-95219778e6fd]
Was this helpful to you?
Quote
jscher2000
  • Top 10 Contributor
8098 solutions 66179 answers

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

Okay, this is not as crazy as it sounds: ''elowney [[#question-1246512|said]]'' <blockquote> 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. </blockquote> 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
Was this helpful to you? 2
Quote

Question owner

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.

''jscher2000 [[#answer-1188138|said]]'' <blockquote> There's a workaround listed here: https://docs.gitlab.com/omnibus/settings/nginx.html#setting-http-strict-transport-security </blockquote> 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.
Was this helpful to you?
Quote
McCoy
  • Top 10 Contributor
319 solutions 2843 answers

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  !

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 !
Was this helpful to you?
Quote
Ask a question

You must log in to your account to reply to posts. Please start a new question, if you do not have an account yet.