[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: end-to-end encryption question

     On Thu, 13 Sep 2007 12:07:08 -0400 Nick Mathewson <nickm@xxxxxxxxxxxxx>

>On Thu, Sep 13, 2007 at 02:56:41AM -0500, Scott Bennett wrote:
>[lines re-wrapped]
>>      In http://tor.eff.org/docs/tor-doc-server.html.en it says,
>> 	14.  If your Tor server provides other services on the same IP
>> 	address--such as a public webserver--make sure that
>> 	connections to the webserver ae allowed from the local host,
>> 	too.  You need to allow these connections because Tor clients
>> 	will detect that your Tor server is the safest way to reach
>> 	that webserver, and always build a circuit that ends at your
>> 	server.  If you don't want to allow the connections, you must
>> 	explicitly reject them in your exit policy.
>>      I have a few questions about the above text.
>> a) Who translates the destination address to  Is it the
>> tor client?  Or is it the exit server?
>Nobody is supposed to translate the destination address to
>  Oh!  I see what went wrong here.  "The local host" is
>not the same as "localhost", but the instructions should be a lot more
>clear about that point.
>The paragraph quoted above is about publicly visible webservers:
>Suppose for example that you have a webserver running at IP
>Suppose that there is also a Tor exit at  If your webserver
>is configured to reject requests from, that's fine.  If your
>webserver is configured to reject requests from, that's no
     Okay.  That takes care of setups involving static, public IP
addresses.  Is there some way to take advantage of end-to-end
encryption here in cases where the tor server and the other service
are both on a private network behind a NAT server?  I.e., if the tor
server is at ("Address") and a web server is at  And what about the case in which they are both on

>> b) If I have "ExitPolicyRejectPrivate 1" in my torrc, does that
>> prevent such end-to-end encryption?  If not, then does an
>> "ExitPolicy reject *:*" at the end of my exit policy list count as
>> "explicitly rejecting" such connections?
>No. is a private address; your public IP is not private.

     Never mind.  The question was obviated by your response to a).
>> c) If "TunnelDirConns 1" tries to build one-hop circuits to
>> directory servers, does "TunnelDirConns 0" result in direct,
>> unencrypted links to directory servers?  Or does it result in the
>> normal, three-hop link encrypted as far as the exit server, then
>> unencrypted to the directory server?  Or does it result in an
>> end-to-end-encrypted link to the directory server?  Do I need to
>> have something like "ExitPolicy accept[dirport]" ahead of
>> the "ExitPolicyRejectPrivate 1" in my torrc to allow it?
>The default behavior is direct HTTP requests to directory servers.
>> d) If normal connections to directory servers are unencrypted at any
>> point along the way, what is the procedure to get them to be
>> encrypted from end to end?
>AllDirActionsPrivate, I believe.
     Is that an undocumented torrc line?  Or is it just a 0.2.*.* feature?
(I'm running at present.  I tried, but it kept crashing. apparently has the same bug, but has crashed that way only once,
so I'm sticking with it for better stability at least until
comes out.)  I gather that that also implies that directory service exits
are not treated the same way other exits are treated w.r.t. the default
attempt to use an encrypted link all the way through the tor server that's
"close to" the tor directory server.

                                  Scott Bennett, Comm. ASMELG, CFIAG
* Internet:       bennett at cs.niu.edu                              *
* "A well regulated and disciplined militia, is at all times a good  *
* objection to the introduction of that bane of all free governments *
* -- a standing army."                                               *
*    -- Gov. John Hancock, New York Journal, 28 January 1790         *