[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 22.214.171.124pre (X11/20080208)
-----BEGIN PGP SIGNED MESSAGE-----
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
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
1.) The directory protocols would have to allow for these extended
2.) The client code would have to take the meshes of firewalled exits
3.) Of course, the server code would have to allow for a firewalled exit
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.
AAS, CompTIA A+/Network+/Security+
Owner of Tor node "kitsune"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----