965616 - Firefox forces https mode for website under all circumstances

Status: RESOLVED INCOMPLETE

(Firefox :: Address Bar, defect)

Description

[Stefan Gofferje]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 2013120700

Steps to reproduce:

I have two hosts configurations on my webserver.
http://home.gofferje.net and https://home.gofferje.net
I try to access http://home.gofferje.net


Actual results:

I am unable to access http://home.gofferje.net with Firefox. Firefox ALWAYS uses https, regardless if I enter a URL manually, click on a link or even click on a bookmark.
I do not have this problem with other browsers on the same machine.
I tried in safe mode - same result.
Of course, no redirection in configured server-side!


Expected results:

Firefox should go to the URL it's told to go to and not make arbitrary undocumented own decisions!

Comment 1

[Stefan Gofferje]

Update:
Did lots of testing. Problem seems to have to do with SSL client auth.
When https site is asking for SSL client auth, FF doesn't allow access to the http site anymore but always enforces https.
I switched off SSL client auth on the https vhost. After accessing the https vhost once, FF allowed access to the http host again. I switched SSL client auth back on. After one access and auth round on the https vhost, FF did not allow access to the http vhost any more. Repeated the test several times. Result is consistent.

Comment 2

[Patrick O'Keeffe]

Mark this CONFIRMED please. 

Stefan, see this support thread: https://support.mozilla.org/en-US/questions/978166

TLDR: FF stashes the Strict-Transport-Security header for visited and bookmarked sites. By redirecting to https, the browser is "working correctly." 

However, the caching IS an issue. Consider the case where I am traveling and using guest wireless internet access. I launch FF and instead of getting my normal homepage (via SSL) I am at a catch-and-release terms acceptance page. Since the 'I agree' page security cert does not match my homepage (or any other in my history), I receive a warning (good) but I cannot manually request the http version of the terms page so I have to a) request some site I haven't visited yet or b) create a security exception to be able click the 'I agree' button. 

I don't think a reliable workaround was identified in the support thread but clearing your history and removing the target site from your bookmarks might be enough to remove the cached header.

Comment 3

[Stefan Gofferje]

Patrick,

My webserver does not send a Strict-Transport-Security header but it does send "Pragma: no-cache" and
"Cache-Control: no-cache"...
Setting Strict-Transport-Security would be fairly stupid when I run a virtual host without https on the same domain, wouldn't it? :)

The only thing I could imagine would be apache sending the header on it's own when client authentication is activated. I would have to investigate this but for the moment I don't believe it because the scenario of having different services on the same domain is not that uncommon.

Comment 4

[Patrick O'Keeffe]

This appears to be less related to Strict-Transport-Security header and more related to FF itself. If you have ever visited a page via https then FF will prefer https even if you explicitly request http. Right-clicking the history entry and choosing 'forget this site' appears to resolve the issue and allow the user to reach the http page.

This bug needs to be marked CONFIRMED and probably downgraded from critical->normal.

w.r.t. explicitly requesting http via awesome bar (location bar) see bug 723622.

Comment 5

[Norbert Preining]

Yeah, I am hitting the same problem over and over again. urlautofill disabled, but still https is selected disregarding whatever I type into the url bar. Also my site does not send Strict-Transport-Security header, so this is not the problem.

Norbert

Comment 6

[Ed]

I'm seeing the same problem. 31.1 on RHEL 5.x. 

I've clobbered my history, set urlautofill and autocomplete.enabled to false. 

No HTTPS site exists for the IP I'm trying to reach. (In fact, this is a case where I'm attempting to log in to an IBM BladeCenter to enable SSL). 

This is problem has been going on for about 2 years. Is there a fix in site for this anytime soon?

Comment 7

[Don Storm]

Disable or remove any anti-virus or anti-malware client and test. Avast security client is one that is known to cause this issue. Test with client removed or disabled.

Comment 8

[Norbert Preining]

(In reply to Don Storm from comment #7)
> Disable or remove any anti-virus or anti-malware client and test. Avast
> security client is one that is known to cause this issue. Test with client
> removed or disabled.

Sorry, I was on Linux, no Avast there ...

Comment 9

[Marco Bonardo [:mak]]

After bug 769348 we don't suggest anymore https by default. but that landed in Firefox 23/24 so it's unlikely the reason behind this bug.
Moreover the awesomebar always respects a typed schema.

So far we could only identify these reasons:
- HSTS
- outdated cache containing a redirect
- Third party software/add-on doing rewrites

All of the reports ended up inside of of these, and none of them were location bar bugs. Since here we don't have any evidence of this being different I'm going to resolve it.
But, if it's still reproducible and all of the three above cases can be excluded, feel free to reopen.