Re: [tor-talk] about tor entry node

[esolve esolve <esolvepolito@xxxxxxxxx>]

what I meant is:

Let me say that an attacker controls some nodes. At a certain time, one of
the controlled nodes is used as entry node by a tor client,  if the
attacker doesn't know that the node is used as entry node, then the
attacker can't identify the client. Even if it examines the IP addresses of
the lists of relays, the suspicious IP may belong to a client or a bridge.

so why tor designer let the attacker know when a controlled node is used as
entry node？



2012/12/7 Sebastian G. <bastik.tor> <bastik.tor@xxxxxxxxxxxxxx>

> esolve esolve:
> >>> besides, why do Tor designers want to let the entry node know that it
> is
> >> an
> >>> entry node?
> >>
> >> Generally:
> >> Entry nodes get the Guard flag so clients know among which nodes they
> >> can pick as their entry points. (Currently three entry guards, that
> >> might change in the future)
> >>
> > ---------------------------------------------------------------------
> > you meant each client can only have 3 entry guard candidates?
>
> A tor client picks three entry guards from the list of relays which got
> the guard flag. The client sets an expiry time from 30-60 days; after
> which it picks again. (It may do that earlier if Guards go down)
>
> > how many entry guards are there in the whole tor network and how are they
> > allocated?
> Around 900 entry guards out of 3000 relays.
>
> See this graph:
>
> https://metrics.torproject.org/network.html?graph=relayflags&start=2012-09-08&end=2012-12-07&flag=Running&flag=Guard&granularity=day#relayflags
>
> > can entry guards be used as normal relay nodes?
>
> Yes entry guards can be at any position in a circuit (if it also got the
> exit flag). (Middle relays are just relays without guard and exit flags)
>
> >>
> >> On each case:
> >> The Tor network is public (beside the bridges) so you know every node
> >> and therefor their IP addresses. Every IP that connects to you, which is
> >> not in the list of IP addresses you know, has to be either a client or a
> >> bridge.
> >>
> > --------------------------------------------
> > actually there are many good conference papers presume that the attacker
> > takes control of an entry node and exit node, then blabla.....
> >
> > so maybe their assumptions are just wrong at the beginning!?
> >
>
> As much as I hope that they would be wrong... they are not. At least not
> to my understanding. If someone, that might be the relay operator that
> controls both entry and exit of a given circuit, or an adversary that
> can look at the traffic of them, can see both ends he can correlate the
> traffic. Based on timing information and traffic volume, for example.
>
> Low latency networks such as Tor suffer from traffic correlation, which
> has not been defeated yet. As far as I know this would be very hard to
> accomplish, if at all.. (I'm not experienced enough with this topic.)
>
> Entry Guards are one attempt to minimize the risk of being exposed to
> traffic correlation. If the client picks three guards that are honest
> (good guards), an attacker won't be able to correlate traffic, while it
> would be more likely to pick a bad entry point if entry guards wouldn't
> have been invented/introduced. (While there still is the case that a
> client can pick bad guards)
>
> To avoid building circuits over nodes that are controlled by the same
> operator, operators can set a "Family" for their nodes, so the Tor
> client would not pick them for the same circuit (also everything in the
> same /16 IP block). Obviously the relay operators have to be honest as
> this is an optional torrc setting and if your are a bad guy I guess you
> wouldn't set it. (The other way around is not true; if it is not set
> although it would be correct doesn't mean the relay operator is a bad guy)
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk