What to do at IP number change?
Jon McLachlan
mcla0181 at umn.edu
Wed Jan 9 04:32:23 UTC 2008
Scott Bennett wrote:
> On Tue, 08 Jan 2008 14:15:05 -0600 Jon McLachlan <mcla0181 at umn.edu>
> wrote:
>
>> dr._no at cool.ms 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 *
> **********************************************************************
>
>
More information about the tor-talk
mailing list