[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #3455 [Tor Browser]: Tor Browser should set SOCKS username for a request based on first party domain
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs