1755622 - Firefox makes spurious requests to "/" when requesting pages with a ".localhost" TLD in private browsing mode

Status: RESOLVED WONTFIX

(Core :: DOM: Security, defect)

Description

[Luke]

Attachment: screenshots.zip

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

1. Add host file entries (on Windows C:\Windows\System32\drivers\etc\hosts), for example:
   127.0.0.1 website.localhost
   127.0.0.1 website.something

2. Setup a local web server to serve files from a directory. I am using Apache 2.4.46 with XAMPP. Example httpd.conf entries are:

<VirtualHost *:80>
ServerName website.localhost
DocumentRoot "C:/xampp/htdocs"
</VirtualHost>

<VirtualHost *:80>
ServerName website.something
DocumentRoot "C:/xampp/htdocs"
</VirtualHost>

3. Create empty files "a" and "b" in the served document root (htdocs folder in the above examples).

4. Navigate to http://website.localhost/a or http://website.localhost/b in a private browsing window.

5. Compare with the results of navigating to http://website.something/a or http://website.something/b in the same private browsing window.

Actual results:

Requests to http://website.localhost/a and http://website.localhost/b in the private browsing window are each followed by an additional request to http://website.localhost/ that looks like this:

GET / HTTP/1.1
Host: website.localhost
User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0
Accept: /
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: no-cors
Sec-Fetch-Site: cross-site
Pragma: no-cache
Cache-Control: no-cache

This request also does not include any cookies for the domain (if there were any).

In comparison, requests to http://website.something/a and http://website.something/b work as expected (a single GET request followed by a 200 OK reply).

Performing the same test in a regular (non-private browsing) window does not produce the spurious "/" request.

Expected results:

No additional request to "/" should be made after a request to a .localhost TLD.

I have attached screenshots of a Wireshark capture showing the unexpected requests. Notice that "/a" and "/b" are each followed by "/" even though I never navigated to the root page. I can reproduce this in a fresh profile with no extensions installed.

It's also worth pointing out that this "/" request does not show up in the "Network" section of the in-browser developer tools.

Let me know if there is any more information I can provide. Thanks in advance!

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Dragana Damjanovic [:dragana]]

Christoph, this sounds like https-first/only. Can you find someone to take a look?

Comment 3

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Dragana Damjanovic [:dragana] from comment #2)

Christoph, this sounds like https-first/only. Can you find someone to take a look?

Moving this over to DOM:Sec so it shows in our next triage meeting.

Comment 4

[Daniel Veditz [:dveditz]]

This is a result of "https-first", which for now is enabled in Private Browsing and which may be enabled generally in the future. When you enter an http: URL we try to connect to the server using https: instead... if we don't get a response quickly (or if it outright fails, which I assume happens i this case) we probe the server on http: to see if the server is actually responding. If it does we then give up on the "https" part and load the requested http: url.

We had a blog about these probe requests in the context of "HTTpS-only", a similar feature
https://blog.mozilla.org/attack-and-defense/2021/03/10/insights-into-https-only-mode/

Is there some problem caused by these probes? Or are you just reporting it because it's unexpected?

Comment 5

[Luke]

Hi Daniel,

I first noticed this behavior while working on a PHP site locally. I saw tons of new sessions being created, because every time I navigated to the page in a private window, Firefox was following up each HTTP request with a second one without any cookies. Which meant every page request re-used its existing session and also created a new session in the background.

Thank you for the link, that is good to know! I still have a question on why HTTPS-Only mode would trigger two HTTP requests. It looks like the intended behavior is for it to send an additional HTTPS request to determine whether to upgrade an HTTP request. But I'm seeing the initial HTTP request (as typed into the address bar), and then a second HTTP request (for the site root) a moment later, after the first request has already been answered.

I experimented with the "HTTPS-Only Mode" settings in the browser options, but now I am a bit more confused.

• I added an HTTPS version of "website.localhost" to my local Apache config, but requests to http://website.localhost/ are not upgraded to https://website.localhost/ even with HTTPS-Only enabled. I can navigate to https://website.localhost/ and receive the same page, which tells me my server is working on both protocols. But why is Firefox not upgrading http:// requests to https://?
• The additional requests to the root page do not happen when HTTPS-Only is enabled. They only happen when "Don’t enable HTTPS-Only Mode" is selected (based on what I see in Wireshark). This seems backwards. If these requests are probes to determine the presence of HTTP, shouldn't they stop if I disable HTTPS-Only? Additionally, are these probes intended to be sent after every regular HTTP request?

Apologies if I'm misunderstanding something, but this feels like a bug with how HTTPS-Only is being handled here. Doesn't the behavior I described above seem wrong?

Thanks,
Luke