1164262 - http being forced to https incorrectly

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[sebtombs]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0
Build ID: 20150401154227

Steps to reproduce:

I can't tell you what causes this, only that it happens for some users and not others (even two sessions on the same machine therefore using exactly the same version of Firefox).

It seems to be the condition described at the end of https://bugzilla.mozilla.org/show_bug.cgi?id=769994 - it is not related to autocomplete but causes https to be forced for a site which is not actually forcing SSL (or, in my case, where there is no SSL certificate for that site)

On the machines/user accounts where it goes wrong, type or paste blah.someurl into the address bar and hit return.

Note: I do not believe that the user has to have typed https://blah.someurl at any time for this to happen. However, it seems probable that it only occurs if someurl itself *does* have an https redirect.


Actual results:

It gets changed to https://blah.someurl

blah.someurl:8040 also gets changed to https://blah.someurl:8040


Expected results:

It should still be blah.someurl, or http://blah.someurl

blah.someurl:8040 should stay the same or become http://blah.someurl:8040


As stated in 769994, the problem still occurs with
browser.urlbar.autoFill -> false
browser.urlbar.autocomplete.enabled -> false 

Clearing history also does not cure it.

Comment 1

[Loic]

is it reproducible easily? Do you have better STR? If not, it will hard to debug.

Comment 2

[sebtombs]

Its easily reproducible for the users that it is happening with but unfortunately I've as yet no idea how to make it happen for someone else. Two users accessing the same site from different sessions running concurrently on the same computer get different behaviour, so it is presumably something getting stored in the profile. However, nothing was deliberately done to make the behaviour change.
The symptoms were that some clients and my wife's comnputer (Mageia 4 32-bit) were initially affected. I checked using this machine (Mageia 4 64-bit) with three different user sessions and all were OK. 5 days later, one of those three user sessions developed the problem but I don't believe I did anything specific to make it happen.
Both 64-bit and 32-bit Linux is susceptible but I can't confirm that Mac or Windows versions are affected.

Comment 3

[sebtombs]

I am hoping that more info can be gleaned from those who reported similar behaviour under https://bugzilla.mozilla.org/show_bug.cgi?id=769994.

Comment 4

[sebtombs]

I have confirmed that, as David noted in comment 153 of https://bugzilla.mozilla.org/show_bug.cgi?id=769994, there is no traffic to the server. Using Wireshark I see that the session which is OK initiates http after the DNS query but the session which has the problem initiates https after the DNS query - no http request even gets sent to the server.

Comment 5

[Th1sISMYPASSWORD]

And I confirm what comment 4 reports. Even after following the instructions in bug #769994 this POS still insists on going HTTPS. Any non-Mozilla browsers work as intended, using an HTTP connection if the URI says "http://" and HTTPS if it says "https://".

On the good news front, at least the sorry bastard is not trying to redirect "ftp://" to HTTPS [ I have also discovered that the FF I'm reporting this from actually supports (read-only) SFTP ].

Comment 6

[Th1sISMYPASSWORD]

Update to comment 5: the culprit site has some pages that set the "Strict-Transport-Security" header (RFC 6797). Once FF has accessed one of the pages sending back the HSTS header, the whole site becomes inaccessible via HTTP.

It appears to be that the RFC is rather ill thought out, as it does not explicitly consider the case where a host may want to enforce HSTS only under part of its content. The only place where I can see where it is hinted at that HSTS is intended to be applied site-wide is section 2.2 (http://tools.ietf.org/html/rfc6797#section-2.2), reading:

> UAs transform insecure URI references to an HSTS Host into secure
> URI references before dereferencing them.

The "references to an HSTS Host" bit being the relevant part.

So I retract comment 5. I'll take it up with the HSTS guys instead.

Comment 7

[Patrick McManus [:mcmanus]]

thanks for investigating - closing as its working as spec'd