Exit Node sniffing solution...an idea...

[Nick Mathewson]

On Fri, Aug 18, 2006 at 08:49:07PM -0700, Anothony Georgeo wrote:
> Hi,
> 
> I have been thinking about the issue of exit node
> operators and/or adversaries sniffing clear-text
> ingress/egress traffic locally and/or remotly on an
> exit node.  I have a possible solution but I would
> like the Tor devs. and experts here to weigh-in. 
> 
> If this won't work feel free to ignore this
> thread...or just belittle me ;-)

Erk.  I hope I'm not *that* rude. :)

 [...]
> --> Possible Solution:
> 
> 4. A couple dozen _fast_ 24x7 exit nodes are run by
> trusted operators (read: known personally by Nick or
> Roger) on a local machine the operators control.

This would pretty much restrict exit nodes to a few places in the US
and Europe, since that's where the exit node operators we know are.
It would limit the scalability of the network pretty badly, and that's
a problem, since we need to accommodate more users, not less.

Also, "A local machine the operators control" would be insufficient
and troublesome.  If we want to lower the likelihood of eavesdropping,
we'd need to make sure it wasn't on an easily eavesdropped network
(like, say, a university net).  "Local" would mean no collocated
hosts, and no hosts at your place of work.

So we'd basically be limited to people that Roger and I know
personally who have very fast network connections to their homes and
who want to run an exit node.  That is not a big list... and because
it's not a big list, it would make us more vulnerable to certain
attacks:

   - End-to-end correlation attacks get easier, since fewer exits
     means fewer points that a roving adversary would need to
     eavesdrop on in order to see all traffic leaving the network.

   - Legal/social/online DOS attacks get easier, since fewer exits
     means fewer people you need to sue/intimidate/flood in order to
     take down the network.

> 5. These trusted exit nodes would be setup as Hidden
> Services (ex. "www.6sxoyfb3h2nvok2d.EXIT.onion").
> 
> 6. Tor would be updated to use these .EXIT.onion nodes
> randomly as it now randomly chooses regular exit
> nodes.
> 
> 7. All Tor traffic exits from these .EXIT.onion nodes.

Technically speaking, hidden exit nodes are a pretty cool idea -- but
I don't think they achieve what you want.  If nobody knows where the
exit nodes are, it's _harder_ to tell whether they're trustworthy,
rather than easier.

Now, perhaps you meant that only Roger and I should know where the
exits were.  But that would create problems:

 - It would turn Roger and me into a single failure point with respect
   to the network.  For obvious reasons, I'd like to *minimize* the
   number of viable attacks on the network that start with "Send thugs
   to threaten Nick"; this would create a new one. ;)

 - It would require us to operate in secret, without oversight.  This
   would reduce confidence in the network.

 - It wouldn't work so well, since an attacker could easily enumerate
   the exit nodes by just making a series of connections via Tor to a
   website they control, and looking at which IPs those connections
   come from.

Still, technically, it's a very cool notion.  I don't think it's
useful *here*, but I kinda hope we eventually come up with something
it's good for, so I have an excuse to implement it. ;)

 [...]
> 10b. Not associating IP's with .EXIT.onion operators
> on the 'closed' list should offer an extra layer of
> anonymity for the operators.
> 
> 10c. Due to the fact an .EXIT.onion node operator can
> not be associated to any perticular .EXIT.onion node
> there may be less liability for the operator.

Again, if you want to know who's running [X].exit.onion, you could
just make a connection to your own website via [X].exit.onion, and see
whose IP it comes from.

Also, if it's not easy to prove that you're running a Tor exit node,
you will IMO have a _harder_ time defending yourself if somebody tries
to accuse you of originating traffic that your exit node delivers.

> 11. ISP's, websites, etc may not be able to block
> these servers as the IP's of the .EXIT.onion nodes are
> not associated to the nodes. (is this correct?).

Being hard to block at the exit side is not a goal of Tor.  We want it
to be _easy_ for websites that don't want anonymous traffic to block
us.  Being blockable discourages administrators from taking an
adversarial stance to our software, and has in several cases actually
encouraged people to improve their authorization systems to not rely
on IP blocking for security.  See
   http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#WhyBlockable
for more rationale.

[...]

yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 652 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20060821/e6c34e33/attachment.pgp>