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

[Anothony Georgeo <anogeorgeo@xxxxxxxxx>]

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 ;-)

--> The Problem:

1. Clear-text traffic can be sniffed by the exit node
operator and/or an adversary remotely and/or locally.

2. There is no current "web of trust" in terms of exit
node operators; anyone can run a exit node.

3. Many services on the 'net (HTTP, POP, etc) do not
offer encrpyted access (HTTPS, POP3s, etc).  This
prevents end-to-end encrypted traffic in may
instances.

--> 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.

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.

--> Possible benifits of .EXIT.onion nodes:

8. These .EXIT.onion nodes are run by trusted
operators who can be resonably trusted not to sniff
traffic.

9. The location of the .EXIT.onion nodes are unknown
to an adversary so in theroy they can not remotely
sniff traffic. (is this correct?)

9a. If an adverary _can_ remotely sniff traffic from
these .EXIT.onion nodes this marginally better than
the current state of affairs where both exit node
operators and adversaries can/do sniff traffic. 

10. The operators of these .EXIT.onion nodes can be
kept on a 'closed' list available to Roger, Nick, etc.
 

10a. This 'closed' list won't contain IP's only
.EXIT.onion address associated with the operators.  

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.

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?).

11a. If an ISP, website, etc tries to block an
.EXIT.onion node the operator can simpally change the
.EXIT.onion node URL.

12. A Hidden Service circuit uses 4 hops not 3.  This
extra node may not help with timing attacks but it may
offer extra security/anonymity in other regards. (is
this correct?)

--> Possible problems with .EXIT.onion nodes:

13. Increased latency inherant in Hidden Services may
deter end-users from using Tor.

14. Increased load/latency to the Tor network due to
the 4 node circuit and latency of Hidden Services.

--> Other conciderations:

15. These trusted .EXIT.onion node operators are
probably already running exit nodes.  It may be trival
for them to move there exit nodes behind Hidden
Services.

16. All current exit nodes would have to go 'off-line'
at the same time (depreceate via. DirSevers over a few
days?).  

16a. This would prevent an observant adverary from
corralating that a few dozen exit nodes dissapered and
a day later the same number of nodes appeared as
.EXIT.onion nodes.  

----------------------------------------------------


Well, thats all I have.  I'm sure I missed something
or I am misunderstanding some basic premise of Onion
Routing II but I'm open to suggestions and
corrections.

Anogeorgeo





  

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com