[tor-bugs] #3455 [Tor Browser]: Tor Browser should set SOCKS username for a request based on first party domain

[Tor Bug Tracker & Wiki]

#3455: Tor Browser should set SOCKS username for a request based  on first party
domain
-------------------------+-------------------------------------------------
     Reporter:           |      Owner:  arthuredelstein
  mikeperry              |     Status:  needs_review
         Type:           |  Milestone:  TorBrowserBundle 2.3.x-stable
  enhancement            |    Version:
     Priority:  major    |   Keywords:  tbb-linkability, tbb-usability,
    Component:  Tor      |  TorBrowserTeam201410, tbb-firefox-patch,
  Browser                |  MikePerry201410R, tbb-4.5-alpha
   Resolution:           |  Parent ID:  #5752
Actual Points:           |
       Points:           |
-------------------------+-------------------------------------------------

Comment (by arthuredelstein):

 Replying to [comment:63 mikeperry]:
 > After a quick look at the Torbutton side of the code -- I am wondering
 what happens with favicons. Historically, Mozilla's filters often miss
 those.

 I made a small test at http://arthuredelstein.github.io/faviconDemo.html,
 which consists of a tiny html page with a link to a favicon. Annoyingly,
 the Firefox network tab does not show the favicon.ico request. So I
 examined the tor-SOCKS conncetion with tcpdump. After clearing the browser
 cache and browsing to the test, I could see two HTTP GET request/response
 pairs through the same socket connection, one for faviconDemo.html and one
 for favicon.ico. So favicon.ico is passing through tor. The first request
 was preceded by a SOCKS username:password request being set to
 arthuredelstein.github.io:0. There wasn't a second username:password
 request.

 But at the same time, watching the tor Control Port, I could see only one
 STREAM event:
 {{{
 650 STREAM 265 NEW 0 arthuredelstein.github.io:80
 SOURCE_ADDR=127.0.0.1:57287 PURPOSE=USER
 650 STREAM 265 SENTCONNECT 63 arthuredelstein.github.io:80
 650 STREAM 265 REMAP 63 185.31.17.133:80 SOURCE=EXIT
 650 STREAM 265 SUCCEEDED 63 185.31.17.133:80
 650 STREAM 265 CLOSED 63 185.31.17.133:80 REASON=DONE
 }}}
 where getinfo circuit-status shows the following info for circuit 63:
 {{{
 63 BUILT
 $9CD77810A49B52A333666689B334447DCAD40591~Unnamed,$43021D98AC4B2EC960233E5B4D7032BE450E6241~thebigpenistorrelay,$AF657ED27ADF08EDB9E4C7EE90DDA5D2C1D46DFC~torpoint
 BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL
 TIME_CREATED=2014-10-29T18:38:13.556569
 SOCKS_USERNAME="arthuredelstein.github.io" SOCKS_PASSWORD="0"
 }}}

 So my interpretation is that Firefox is pipelining the favicon.ico request
 after the initial page request. I tried to turn off pipelining by various
 browser prefs, but without success.

 Looking at the Firefox source code, however, I get the impression that if
 pipelining weren't happening, the favicon would not be sent over the same
 username+password. So it would still be better to try to fix this.

 > I am also wondering how this interacts with requests from the addons
 pane. Neither of these are blockers, but we should be aware of these
 issues if they exist.

 At the moment, requests from the addons pane appear to be sent through the
 "default" tor circuit -- i.e, one with no SOCKS u+p. I figure this is not
 so serious, but it would be nice to fix in a future iteration.

 One more serious issue that I just discovered, is that OCSP requests are
 being sent on the default circuit. Obviously this needs to be fixed.
 Somehow we need mozilla.thirdPartyUtil.getFirstPartyURIFromChannel to
 return the URL bar domain for the requesting page.

 (This OCSP issue seems possibly tangentially related to #3666, but I
 couldn't find the relevant patch in tor-browser.git. Has the patch been
 upstreamed to Mozilla already?)

 > I am also a little concerned with your initialization.
 DomainIsolator.observe() is actually going to be called for several
 different observer topics. It may be causing multiple proxy filters to get
 registered. You should probably be checking for topic == "profile-after-
 change".

 Good point. I've fixed that in the latest version of the patch.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/3455#comment:64>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online