Closed Bug 1373388 Opened 4 years ago Closed 4 years ago
Captive portal detection request keep-alive socket reused in private browsing windows
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.
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?
Assignee: nobody → valentin.gosu
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?
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.
Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.