[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: What to do at IP number change?

Scott Bennett wrote:

     On Tue, 08 Jan 2008 14:15:05 -0600 Jon McLachlan <mcla0181@xxxxxxx>
wrote:

dr._no@xxxxxxx wrote:
Another point is that without a tor server my home would be vulnerable to traffic analysis and a further point is that a tor server is more safe than only a client.
I think this depends largely on what type of traffic analysis we're talking about. Traffic analysis, just looking at traffic, almost always divulges some level of information. For example, if a local passive adversary simply watched a Tor Relay that was suspected to also contain a Tor Client, then one could imagine a simple traffic analysis as follows:
1) Establish running totals of all incoming and outgoing traffic from the machine.
2) Then, closely monitory when it is the case that the outgoing traffic level "spikes" or when the incoming traffic level "spikes" as they could indicate that a Tor Client was using the relay as an entry point. How much it "spikes" could fingerprint a website ... or even be a maliciously modulated signal from an evil server might you might have connected to via your tunnel.
This exploits the behavior of a basic Tor Relay, in which everything that enters a relay must [immediately] leave that relay. This traffic alone would generate what appears equal/average incoming and outgoing msgs. Any spikes in the entering / leaving traffic is therefore probably not from the Tor Relay itself, but, from something else. (or course, this ignorse dir service lookups, bridges, and prly a few other things). 

     Almost.  If you have an asymmetric broadband service and are not
specifying BandwidthRate or BandwidthBurst in torrc, then your tor server
is likely to top out around the transmission rate limit of your Internet
connection.  At this point, only input spikes would be visible.  When data
come in faster than they can go out, the cells just stay in an output queue
until they can be sent.  If this goes on over an extended period of time,
it will have at least a partial smoothing effect upon the inflow as well
due to TCP source quench packets being returned.
     Note also that spikes may occur for several other obvious reasons,
e.g., a new stream on a circuit going through your tor server that is used
for FTP, downloading large files (e.g., music or video or CD/DVD image
files), or NNTP batch transfers.  Spikes often have nothing to do with a
local client.
Yeah, I guess I was making synchronized assumptions, haha :). But, I am having trouble imagining circuit based Tor relay traffic causing "spikes" in the differences between total incoming traffic and total outgoing traffic - since, if there were large discrepancies between these two totals, it would more or less be a kind of measure on your own relay's lag. In a low-latnecy system, one of the centric goals is to minimize this - and in Tor, I believe several design decisions were based around this. So, even if things are async, it seems likely that (large, consistent) discrepancies between total incoming/outgoing traffic would prly be due to "other" local traffic that either originates or exits form the relay. But yes, I was also assuming a strong local passive adversary that is able to distinguish between circuit relay traffic and all other (ignored) network traffic. 
Sounds like an interesting research project.



                                  Scott Bennett, Comm. ASMELG, CFIAG
**********************************************************************
* Internet:       bennett at cs.niu.edu                              *
*--------------------------------------------------------------------*
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *
**********************************************************************