[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>
+>Scott Bennett wrote:
+>> On Tue, 08 Jan 2008 14:15:05 -0600 Jon McLachlan <mcla0181@xxxxxxx>
+>>> 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
+>> 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
The web site address above is incorrect. It should be www.tbc.net.
My apologies for the noise.
+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 *