[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
A way to allow firewalled exit nodes [Was: Re: getting more exit nodes]
- To: or-talk@xxxxxxxxxxxxx
- Subject: A way to allow firewalled exit nodes [Was: Re: getting more exit nodes]
- From: "F. Fox" <kitsune.or@xxxxxxxxx>
- Date: Mon, 28 Apr 2008 17:17:48 -0700
- Delivered-to: archiver@xxxxxxxx
- Delivered-to: or-talk-outgoing@xxxxxxxx
- Delivered-to: or-talk@xxxxxxxx
- Delivery-date: Mon, 28 Apr 2008 20:17:48 -0400
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; bh=dWPtHwXmtxJk1mH3kVZULidQww2oQrz0yhXiExCiMqI=; b=EWGFcF4BLAiVgiMBgInUIODXsn5Lq74lHaU9keDT2jRrIupcDzEw7KBnRdJz+dp7eWBLEXZvFKQp3fqU1la20I8pRpn2djm8ON2FaGq/CZiLRavxh9n5SY591Bx9/SetY3OScJ1yzLsR5rD/RpfAldvPKvKSjBfRvN+p5seZ0UQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references:in-reply-to:x-enigmail-version:content-type:content-transfer-encoding; b=BN0NF7iD/40CVja8cwWhZv/dfQJjIlgjC5U+ZMFPxuuSddvf6fgqqp269+8gWGMI7zKop279RI8QE/ALCrAIZd7V2aTz0BeFyAa8anbCrctwPUh4idcLRkSVRVCGFwY0jfQpRrFfCu3k2Nqs5NgdRkX8natnSZ18Dq1wuxJTIzU=
- In-reply-to: <200804280136.m3S1aJct022202@xxxxxxxxxxxxx>
- References: <200804280136.m3S1aJct022202@xxxxxxxxxxxxx>
- Reply-to: or-talk@xxxxxxxxxxxxx
- Sender: owner-or-talk@xxxxxxxxxxxxx
- User-agent: Icedove 1.5.0.14pre (X11/20080208)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
I think that adding a "firewall-piercing" rendezvous-type system (like
STUN, or I2P's SSU) to allow heavily-firewalled nodes to act as exits -
ON A STRICTLY VOLUNTARY BASIS (i.e., off by default) - might be a nice
feature.
I can think of one potential problem, though - I don't know if such a
firewalled exit could be reliable, from the client POV. The problem
isn't so much from the general way connections are made on the Net, as
it is in the trust-no-one model of how onions are formed.
It's possible, but to preserve both the encryption from the injection
into the Tor clould to the exit node, and the TNO model, here's what
we're looking at:
1.) A firewalled node - we'll call it Router X - opens a number of
connections (the more the merrier, since it will complicate traffic
analysis) - to non-Guard and non-Exit nodes; we'll call these Routers A-M.
2.) Router X would publish an extended server descriptor, which would
include the list of nodes it's meshed with - in this case, Routers A-M.
3.) If a client, choosing nodes randomly, includes a firewalled node, it
would take that published list into account, so that it wouldn't put
adjacent layers on the onion that couldn't be handled by its neighbors.
(So, the client couldn't put a layer for Router Z right over Router X,
because Router Z wouldn't be able to contact Router X.)
4.) So, let's say the client layered an onion to pass from some random
Router Y --> Router A --> Router X. When the transfer starts, Router X
can act as an exit, even though it's firewalled.
***
It's an interesting solution from a pure hackery point-of-view; however,
the Occam's Razor part of me seriously questions whether it'd be worth it.
For one, we'd be talking about a serious overhaul of some code; in
particular:
1.) The directory protocols would have to allow for these extended
descriptors;
2.) The client code would have to take the meshes of firewalled exits
into account;
3.) Of course, the server code would have to allow for a firewalled exit
option.
I thought I'd throw it out there, just for the hell of it - but my
personal opinion is, Tor is actually working far better than I had
expected. It's improved over the past year or so, and I don't think a
solution like this would be worth either the work, or the potential risk
of new bugs or attacks it could open up.
- --
F. Fox
AAS, CompTIA A+/Network+/Security+
Owner of Tor node "kitsune"
http://fenrisfox.livejournal.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBSBZpLOj8TXmm2ggwAQhQqQ/5ASXel2t4ISJ+F3uC9Fn+FOp0LYSZjsq9
SgrxrWe4OEXPL1cD+cOVYXDi1+WHQPIMuu4UAJ59oNVDraQ0yv79OOW1xQb6JITY
MdjhPOwUsznaVs3D1/dhG/UUAHVfrlavfjUCbVWAMdDLONvrR35hBxkaBLaZ0mJ+
90EbtL9U91L2/ty0adAydJRxXWwmqm5nphXneLyJrLj5hVQUB0BPL792DDQi2uXH
M4bIpdcCqQWgzZKlONjWOIGHruvcQoe20fPFRE8wYcU5NwqY0puKtuCPd6+tWUBw
APY7uMBPANGzGnx4DTaMzHVkykeEeiFmjQJfrqcouQerqABQi5MZ7Uvmx/uJMvpI
FO7cgnWHOxkmNAmym8aVLkvyIVcXa87+eFBp9cUnnUxLSxd9u9SKw7nF6R/tqou/
c59ZqmzvcfmcssbXzOG0UgJrRYljPbKpyFsOkTs0Jp2defzXVs0cNpvFfieQB4MH
QueBK8YHE3G/7K+Hjsfs47pPJjXOuydcPLob1k0FeetuCZ28YxqDmmbIQoJHHyZM
CE93cKmmMgma5NOBp0XoT+e+lMMO2q5vbOlVb6DoZ2so5YTOXuhunslybO7GiMyM
XryOcPZisWLSKt7N1X2IYQwHdQTlRM46tntSF+PnitN3JCS6ZOjVSjbJccOjn79h
v9PaiFK8Aag=
=nnXu
-----END PGP SIGNATURE-----