Re: [tor-bugs] #18762 [Applications/Tor Browser]: implement first-party isolation for OCSP generated by speculative connect

[Tor Bug Tracker & Wiki]

#18762: implement first-party isolation for OCSP generated by speculative 
connect
--+
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  closed
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:  worksforme
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+
Changes (by gk):

 * status:  new => closed
 * resolution:   => worksforme


Comment:

 Setting this to `WORKSFORME`. However, this still needs to get done on
 Mozilla's side when upstreaming our patches.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18762 [Applications/Tor Browser]: implement first-party isolation for OCSP generated by speculative connect

[Tor Bug Tracker & Wiki]

#18762: implement first-party isolation for OCSP generated by speculative 
connect
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by arthuredelstein):

 Replying to [comment:3 gk]:
 > I was looking a bit closer at a thing which was nagging me while doing
 the review for #16998. There is
 > {{{
 > // Check for proxy information. If there is a proxy configured then
 a
 > // speculative connect should not be performed because the potential
 > // reward is slim with tcp peers closely located to the browser.
 > }}}
 > and this piece of code in `nsIOService.cpp`:
 > {{{
 > NS_IMETHODIMP
 > IOServiceProxyCallback::OnProxyAvailable(nsICancelable *request,
 nsIChannel *channel,
 >  nsIProxyInfo *pi, nsresult
 status)
 > {
 > // Checking proxy status for speculative connect
 > nsAutoCString type;
 > if (NS_SUCCEEDED(status) && pi &&
 > NS_SUCCEEDED(pi->GetType(type)) &&
 > !type.EqualsLiteral("direct")) {
 > // proxies dont do speculative connect
 > return NS_OK;
 > }
 > }}}
 > And it seems to me we hit this code path with Tor Browser. Retesting
 #16324 by looking at `tcpdump` output confirms my suspicion as well: there
 is no network activity visible even if Torbutton claims isolation is
 happening.
 >
 > So, it seems to me that at least this ticket and #16324 can be closed. I
 am not sure yet what this means for #16998. I guess, we should not have
 been worried by it because there is no speculative connect happening
 anyway?

 I watch for STREAM events in the browser console and I can confirm that
 the speculative connects don't seem to be causing any network activity. So
 I agree that this ticket and #16324 can be closed. However, I did notice
 that under some special situations, a favicon is displayed in the
 searchbar popup which causes a connection over the catchall circuit; see
 #19741.

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs

Re: [tor-bugs] #18762 [Applications/Tor Browser]: implement first-party isolation for OCSP generated by speculative connect

[Tor Bug Tracker & Wiki]

#18762: implement first-party isolation for OCSP generated by speculative 
connect
--+--
 Reporter:  arthuredelstein   |  Owner:  tbb-team
 Type:  defect| Status:  new
 Priority:  Medium|  Milestone:
Component:  Applications/Tor Browser  |Version:
 Severity:  Normal| Resolution:
 Keywords:  tbb-linkability   |  Actual Points:
Parent ID:| Points:
 Reviewer:|Sponsor:
--+--

Comment (by gk):

 I was looking a bit closer at a thing which was nagging me while doing the
 review for #16998. There is
 {{{
 // Check for proxy information. If there is a proxy configured then a
 // speculative connect should not be performed because the potential
 // reward is slim with tcp peers closely located to the browser.
 }}}
 and this piece of code in `nsIOService.cpp`:
 {{{
 NS_IMETHODIMP
 IOServiceProxyCallback::OnProxyAvailable(nsICancelable *request,
 nsIChannel *channel,
  nsIProxyInfo *pi, nsresult
 status)
 {
 // Checking proxy status for speculative connect
 nsAutoCString type;
 if (NS_SUCCEEDED(status) && pi &&
 NS_SUCCEEDED(pi->GetType(type)) &&
 !type.EqualsLiteral("direct")) {
 // proxies dont do speculative connect
 return NS_OK;
 }
 }}}
 And it seems to me we hit this code path with Tor Browser. Retesting
 #16324 by looking at `tcpdump` output confirms my suspicion as well: there
 is no network activity visible even if Torbutton claims isolation is
 happening.

 So, it seems to me that at least this ticket and #16324 can be closed. I
 am not sure yet what this means for #16998. I guess, we should not have
 been worried by it because there is no speculative connect happening
 anyway?

--
Ticket URL: 
Tor Bug Tracker & Wiki 
The Tor Project: anonymity online
___
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs