[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] TOR issues
Hollow Quincy writes:
> Dear TOR community,
>
> I spend some time to understand how TOR works. I still cannot
> understand some design assumptions. Could you please help me to
> understand some issues ?
I think some of your questions are based on misunderstanding the
difference between circuits that exit to public Internet services, and
circuits that terminate at Tor hidden services. These are two separate
Tor features, and each circuit (that eventually reaches some service)
terminates in one way or the other but not both at the same time.
> 1) Who store the mapping Onion_URL to real IP ? How exit node know
> where to send request ?
Exit nodes aren't used for hidden services at all. Onion URLs are only
used to refer to hidden services, which communicate entirely within the
Tor network and don't exit. Most uses of Tor use exit nodes to reach
public services on the ordinary Internet, instead of using onion URLs.
The hidden service directory mapping is performed by the hidden service
directory. :-)
> 2) How to become Exit Node ?
> I understand that everyone can become normal node. If I become exit
> node even for some requests I can find mapping Onion_URL to real IP.
> Than IP of the page is not secret any more.
Everyone can become an exit node by declaring a non-empty exit policy.
That does allow them to monitor user communications and see where the
users are connecting. In Tor's design this is not considered bad,
because the _identity_ of those particular users should still be hidden
(although it's potentially bad in some threat models, like when the
same adversary operates, or monitors, both the entry and exit points of
a particular user simultaneously).
Exit nodes (or at least their exit service!) are not used in any way
for contacting hidden services. Hidden services and hidden service
users communicate entirely within the Tor network. (Hidden services
themselves build Tor circuits in order to talk to their users.)
> 3) How the communication is encrypted between nodes ?
> RSA encryption is not resistant for Man In The Middle attack. (that's
> why when I connect to new SSH server I need to add public key of the
> server to trusted list).
> When I use TOR my request goes to Node1 and than to Node2. How can I
> establish save connection with Node2, when Node1 is between us ?
Each Tor relay has its own public key which it declares when registering
with the Tor directories. The Tor directories confirm that they have
the same view of the relays on the network, and the relays' public key,
through the consensus mechanism.
That means that the Tor directories are something like certificate
authorities or PKI for the regular Tor relays. You have to trust the
consensus of the directories to give you the correct public keys for the
relays you plan to use, so that no relay (or ISP) can perform an
undetected man-in-the-middle attack.
https://www.torproject.org/docs/faq#KeyManagement
> 4) Is there a single point of failure ?
> There need to be one central place where all IPs of TOR nodes are
> stored, so when I run my TOR bundle I go to this place and read node
> list and send requests using it. So if this place is down (for example
> because DDOS attract) new users will not be able to use TOR network.
> They will not find any TOR node.
The directory authorities, for some purposes, might be the single point
of failure you're looking for. Since they have some redundancy, you
might not call them a "single" point of failure, but they could be seen
collectively as a point of failure because they need to be operating and
reachable in order for users to be able to learn how to connect to the
Tor network.
--
Seth Schoen <schoen@xxxxxxx>
Senior Staff Technologist https://www.eff.org/
Electronic Frontier Foundation https://www.eff.org/join
815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107
--
tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk