1507787 - Redirection loop due to futile but persistent request upgrade attempt

Status: RESOLVED DUPLICATE of bug 1419222

(Core :: Networking: HTTP, defect)

Description

[Markus Wollny]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

Steps to reproduce:

After doing some tweo or three dozen clicks on an unencrypted site I suddenly get a too many redirects error. The error persists when I click the "Try again" button, but the page loads fine again when I simply hit Enter in the navigation bar. URL called via click on a link: http://www.pcgameshardware.de/Test/
UA is Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:63.0) Gecko/20100101 Firefox/63.0, Firefox reports version 63.0.3.


Actual results:

Reviewing requests in network tab shows:
GET to https://www.pcgameshardware.de/Test/ (note the https);
response header is
HTTP/2.0 301 Moved Permanently
date: Fri, 16 Nov 2018 12:07:21 GMT
content-type: text/html; charset=iso-8859-1
content-length: 243
location: http://www.pcgameshardware.de/Test/
cache-control: max-age=0
expires: Fri, 16 Nov 2018 12:07:21 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
cf-ray: 47a9d63a6d34c300-FRA
X-Firefox-Spdy: h2

Note the http (not https) in the location header. But there is no subsequent request by Firefox to the unencrypted URL. Instead Firefox ignores the http and again calls GET to https://www.pcgameshardware.de/Test/ - with the identical result. This is repeated for a total number of 10 GET requests to the https-URL until the error message appears.

Note that this takes some time to reproduce - it doesn't happen on every click, it takes at least a few dozen attempts before it occurs.


Expected results:

Firefox shouldn't have requested the https-URL via click on a relative link href="/Test/" on an unencrypted page in the first place. But if it did in the hope of upgrading the request on its own, even though the webserver didn't honor the "Upgrade-Insecure-Requests: 1" in the request, it should follow the location header to the http-URL and not change that to https again (i.e. simply do a GET to http://www.pcgameshardware.de/Test/). Note that there is no Strict Transport Security Header sent by the server. Subsequent explicit requests to the same http URL (i.e. when pressing Enter in the navigation bar) are working alright.

Comment 1

[Markus Wollny]

I just checked SiteSecurityServiceState.txt - neither of the affected hosts/domains are listed there, so it's not an issue of HSTS having been active some time in the past that's causing this.

Comment 2

[Markus Wollny]

Attachment: Archive 18-11-16 17-00-10.har

Please find attached a HAR file of the redirect loop. You'll see the Location: http://www.pcgameshardware.de/Test/ which are not followed, instead https://www.pcgameshardware.de/Test/ keeps being requested.

Comment 3

[Honza Bambas (:mayhemer)]

Apparently (*.)pcgameshardware.de is on the HSTS list.  It makes us upgrade any request to http://(*.)pcgameshardware.de to be made to a secured origin (https).

I'm afraid that this is a misconfiguration of the server.

Comment 4

[Markus Wollny]

(In reply to Honza Bambas (:mayhemer) from comment #3)
> Apparently (*.)pcgameshardware.de is on the HSTS list.  It makes us upgrade
> any request to http://(*.)pcgameshardware.de to be made to a secured origin
> (https).
> 
> I'm afraid that this is a misconfiguration of the server.

Hello Honza,

Could you please give some more detail about how you did arrive at that conclusion?

(*.)pcgameshardware.de never had HSTS active. SiteSecurityServiceState.txt does not show any entry matching the domain or any subdomain thereof when the error happens. I have made a backup of that file, which had 216 lines at the time the problem occured, though I don't wish to post it here for privacy reasons - you'll need to trust me on this: the string pcgameshardware is nowhere to be found in there.

We never ever had configured HSTS for this host nor any subdomain either. And supposing there ever was a HSTS entry and this was cached, which, again, there wasn't, Firefox would surely have stuck to attempting to upgrade that request when the URL was simply entered again in the navigation bar, which it didn't. One could simply focus the navigation bar, set the cursor at the end of the current URL, press Enter and the page would load just fine unencrypted. Only pressing the "try again" button kept requesting with https schema and ignoring the http-redirect. One could also enter the https://www.pcgameshardware.de/Test/-URL in the navigation bar and the webserver would respond with the location to http and Firefox would happily comply - immediately after it had just failed to do that and entered the redirection loop. Firefox was the only browser that showed that behaviour, we didn't ever see this with Chrome, Opera, Safari or Internet Explorer. So absolutely everything points to bad behaviour on behalf of Firefox, there is definitely no indication of a server misconfiguration for the aforementioned host or domain.

I readily admit that there is a lot of advertising placed on that page, loading a lot of external resources. If I was to take an educated guess, I suspect that some ad or tracking got Firefox mangled, maybe with some mixed content policy implementation (even though the parent document is unencrypted) or a HSTS header sent by one of these external resources - though definitely not for the host www.pcgameshardware.de or the domain.

The problem could not be reproduced in anonymous mode or with an Adblocker active. I followed a recommendation by a CloudFlare support engineer and cleared the browser cache and could not reproduce the problem since.

Comment 5

[Honza Bambas (:mayhemer)]

Then it's likely a duplicate of bug 1419222.