[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: What to do at IP number change?
On Tue, 08 Jan 2008 22:32:23 -0600 Jon McLachlan <mcla0181@xxxxxxx>
wrote:
>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
My computer spends many hours per day during which tor is the only
thing doing any significant volume of network traffic. (The only other thing
accessing the net at those times that comes to mind is ntpdate running once
every hour, which is trivial.) During that time, I see network traffic varying
widely, especially on the input side. I'm not doing anything that accesses
the network at those times, so local use is not a factor.
>strong local passive adversary that is able to distinguish between
>circuit relay traffic and all other (ignored) network traffic.
Actually, the presence of non-tor traffic would just make things more
difficult. Remember that exit traffic bears no marks of distinction from
other locally generated, non-tor traffic. Traffic generated by other machines
on the same local net as the tor server machine is not distinguishable by
IP address if the local net lies behind a NAT+RDR-serving router. Traffic
identifiable by port number as being tor traffic appears simply as unidentified
tor traffic, but its flow rate may be determined as much by the total volume
of other traffic entering and leaving the local net as by the external and
local tor-related demand.
My lousy ISP (TBC Net, Inc. at www.tbcnet.net) cuts the connection at
least once a day, often more than once in a day. Upon reconnection, the
IP address assigned has usually changed, but not always. On the rare occasions
that the IP address has not changed, it sometimes happens that my tor server
will get marked as "stable" by the directory authorities in the directory
information. After a disconnection and reconnection with the same IP address,
the traffic rebounds quickly. As long as the server is not listed as "stable",
traffic varies a lot around the clock, but in those cases where it gets marked
"stable", the traffic tends toward a steady, maximum-output-rate load within
two or three hours of the "stable" listing in the directory. In this case,
few, if any, output peaks are possible and output troughs are unusual. Input
peaks and troughs are sometimes visible, but due to the maxed out output
bandwidth, little change appears in the output signal. In order to see such
peaks and troughs, one would have to have access to the output queue lengths
and volumes on the tor server's machine and on any router connecting the local
net to the Internet.
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 *
**********************************************************************