Torbutton Documentation - Adversary Capabilities. - fork: Normalization of XHR requests

[Paul Syverson]

On Tue, Jul 13, 2010 at 03:30:57PM +0800, John Barker wrote:
> On this subject.
> 
> I assume that all javascript requests actually use your browsers
> HTTP/socket engines - therefore although javascript is able to send
> network requests, they'll still be going through Tor.
> 
> This means that you could be identified by timing attacks, a
> particular sequence of Javascript XHR requests could uniquely
> identify Tor users because basically Tor doesn't do all that much
> normalisation (batching, delaying etc) of requests.
> 

Tor doesn't do any batching or delaying.  This is just another way you
could be identified by timing attacks. Tor provides no resistance to
timing attacks, and so far there are no countermeasures that have
been identified as working against a passive, much less active, adversary
without imposing unacceptably high overhead or limitations. Most have
these limitations and still don't work.

See the blog post
http://blog.torproject.org/blog/one-cell-enough

> Perhaps it would be possible for Tor to do some limited batching for
> XHR requests? I understand Tor is capable of some limited
> application scrubbing - couldn't it see the HTTP headers that
> indicate a XHR request and treat them differently?
> 
> Since XHR requests are typically quite interactive, delaying them
> might make Ajax javascript heavy websites sluggish or unusable, but
> it's just an idea I'm throwing out. Websites are definitely moving
> towards more javascript usage and it would be good to reduce this
> weakness.
> 
> 
> 
> On 13/07/2010, at 6:47 AM, Matthew wrote:
> 
> > Hello,
> > 
> > I have been reading the Torbutton documentation (thanks, guys) and have a question about the adversary capabilities.  
> > 
> > The first adversary capability is "inserting javascript".  The document says that "If not properly disabled, Javascript event handlers and timers can cause the browser to perform network activity after Tor has been disabled, thus allowing the adversary to correlate Tor and Non-Tor activity and reveal a user's non-Tor IP address."  
> > 
> > The third adversary capability is "inserting CSS".  The document says that "CSS can also be used to correlate Tor and Non-Tor activity and reveal a user's Non-Tor IP address, via the usage of CSS popups - essentially CSS-based event handlers that fetch content via CSS's DEFANGED_Onmouseover attribute. If these popups are allowed to perform network activity in a different Tor state than they were loaded in, they can easily correlate Tor and Non-Tor activity and reveal a user's IP address."
> > 
> > I understand that Torbutton is useful for protecting privacy in multiple ways.  But I would like to address this specific issue if I may.
> > 
> > Let us imagine that a user surfs the net using Tor (and Polipo or Privoxy).  He has JavaScript installed and uses it for all sites.  He finishes his activities and then closes his browser.  He then wipes the following files and directories (I am using Ubuntu as my example):
> > 
> > /.mozilla/firefox/nameofuser/cookies.sqlite 
> > /.mozilla/firefox/nameofuser/downloads.sqlite 
> > /.mozilla/firefox/nameofuser/cookies.sqlite-journal
> > /.mozilla/firefox/nameofuser/places.sqlite 
> > /.mozilla/firefox/nameofuser/places.sqlite-journal
> > /.mozilla/firefox/nameofuser/formhistory.sqlite
> >  
> > /.mozilla/firefox/nameofuser/Cache/
> > 
> > Now I assume that these Javascript events and handlers and the CSS handlers were downloaded into the Cache from when the user was browsing using Tor.  They would then be deleted as detailed above. Therefore, when the user loads up Firefox and turns off the Tor proxy settings, presumably the potential for JavaScript or CSS to connect Tor and non-Tor activity and get the users real (non-Tor) IP address is no longer a concern?
> > 
> > Is this correct?  Or am I missing something?  Just to re-state: I am only looking at this one issue - I am well aware of how useful Tor button is in other areas!
> > 
> > Thanks. 
> > 
> 
***********************************************************************
To unsubscribe, send an e-mail to majordomo at torproject.org with
unsubscribe or-talk    in the body. http://archives.seul.org/or/talk/