1373388 - Captive portal detection request keep-alive socket reused in private browsing windows

Status: RESOLVED WONTFIX

(Core :: Networking, defect)

Description

[dpk]

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170608105825

Steps to reproduce:

Start fresh -- kill all firefox processes.
Open WireShark (simply to monitor what's going on).
Open Firefox.
Open a new Private Browsing window within the keep-alive timeout window (115 seconds?).

I've tested this on Firefox 54.0, 32-bit, running on Windows 10.


Actual results:

In Wireshark you'll see that opening Firefox initially generates a request to http://detectportal.firefox.com/success.txt . Opening a private browsing window generates a new request but it re-uses the socket created when the regular window was opened.

The same issue happens in reverse -- open private browsing, verify that it created a new connection, then open a regular window. You'll see it re-uses the socket there, too.

I don't believe this represents a security issue; at least I haven't been able to come up with a way to exploit it. No data is shared between the windows and there does not appear to be a way to differentiate between the request that is made every time you open a new window, period, and the request made when you specifically open a private browsing window.


Expected results:

I expected the browser to sandbox the captive portal detection requests, by which I mean I expected that the browser would, at the very least, open a brand-new socket before making the request upon opening the private browsing window.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

The captive portal service lives in the parent process, and even though opening a new PB window may trigger a captive portal recheck, the check is done in the captive portal service, regardless of the event that triggered it.
At the moment, we set a few flags on the channel:
> captivedetect.js:38
>  // Prevent privacy leaks
>  xhr.channel.loadFlags |= Ci.nsIRequest.LOAD_ANONYMOUS;

We could potentially also set the LOAD_FRESH_CONNECTION - which would disable socket reuse, but I don't think that gives us any privacy benefits.

Patrick, do you see a potential issue with our current behaviour?

Comment 2

[Patrick McManus [:mcmanus]]

you don't want fresh_connection all the time.

however, for normal browsing the PB conns are partitioned from non-pb conns.. it's the P attribute in the nsHttpConnectionInfo hash key.

any chance for plumbing that through to the captive portal service?

Comment 3

[Valentin Gosu [:valentin] (he/him)]

In that case, I don't think it's worth to change anything here.
Since the request is always issued by the non-PB-window, and there is no info that can leak from this, I think our current setup is ok for the moment.