[tor-relays] Filtering TOR Non-exit Relay - Just Curious

Nelson nelson at net2wireless.net
Mon Oct 28 00:27:19 UTC 2013


On 10/27/2013 4:49 PM, Zack Weinberg wrote:
> Lukas Erlacher <l.erlacher at gmail.com> wrote:
>>> Middle nodes don't know the type of traffic. If they have any way
>>> to find out, that is a bug that needs to be fixed. End-of.
> 
> Packet timing analysis may be able to tell you *something* -- this is
> part of my current research project, ask again in six months :-)
> 
> Mr. Nelson Laurenti wrote:
>> I didn't say I knew the type of traffic on my relay, that would be an
>> entirely new set of problems; I said I can see the IP addresses
>> coming in and going out, and the ports used.
> 
> That's to be expected.  Tor is still using IP, so there is no way around
> the fact that a relay operator can observe the IP addresses of hosts in
> direct communication with their relay(s).
> 
> If your relay is acting strictly as a middle hop, however, the IP
> addresses you observe should all be the addresses of other Tor relays,
> and none of the traffic you observe should *originate* from the IP
> addresses you observe.
> 
> If you are an entry hop, some of the traffic you observe will be traffic
> coming directly from clients, and you can learn their IP addresses and
> probably quite a bit about them.  This is part of why we have guards. (I
> am skeptical about guards actually being a good idea, but that's *also*
> part of my group's research, so, again, ask again in six months.)
> 
> Only if you are an exit node should you be able to observe any traffic
> that is in cleartext and/or coming directly from server hosts.
> 
> It is possible for one Tor process to serve all three roles
> simultaneously, but never (by design) for a single circuit.  The design
> intent is that it will be prohibitively difficult for any single
> operator to control more than one node in a circuit more than some tiny
> fraction of the time; how feasible this actually is in real life has
> been the subject of quite a bit of research already (and, yep, my group
> is looking at that as well, albeit not as centrally).
> 
> zw

ZW, thanks. I will definitely check back in six month and see what kind
of progress has been made.

Again, I tested this and with PeerBlock I can actually block known ip's
of the nodes you mention (not something TOR is intended for, or I want
to do or need to do), and for all intents and purposes if "my
organization" had sufficient resources, knowing that we could actually
create blocklists to prevent traffic coming to and from unwanted middle
and exit nodes, then will be in effect "shaping traffic flow"?
Considering of course "we" had "several" relays ourselves?




More information about the tor-relays mailing list