Re: end-to-end encryption question

[Scott Bennett <bennett@xxxxxxxxxx>]

     On Wed, 19 Sep 2007 01:07:18 -0400 Roger Dingledine <arma@xxxxxxx>
wrote:
>On Thu, Sep 13, 2007 at 12:07:08PM -0400, Nick Mathewson wrote:
>> >      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 127.0.0.1?  Is it the
>> > tor client?  Or is it the exit server?
>> 
>> Nobody is supposed to translate the destination address to
>> 127.0.0.1...  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.
>
>Actually, this isn't true. "The local host" in this text is the same as
>localhost. It is 127.0.0.1.
>
>> The paragraph quoted above is about publicly visible webservers:
>> Suppose for example that you have a webserver running at IP 1.2.3.4.
>> Suppose that there is also a Tor exit at 1.2.3.4.  If your webserver
>> is configured to reject requests from 127.0.0.1, that's fine.  If your
>> webserver is configured to reject requests from 1.2.3.4, that's no
>> good.
>
>If your webserver rejects requests from 127.0.0.1, that's bad, and it
>will break people trying to reach your website from your Tor server.
>
>The reason for this is that many modern OSes look at the destination
>(1.2.3.4), realize they've got a better route for that, and decide to
>route it via 127.0.0.1.
>
     Hmmm...I could be mistaken, of course, but AFAIK a BSD kernel will
do no such translation.  By "modern OS" do you mean something like a pf
rule on a BSD system?

>(This might not be true for your favorite OS -- I'm not sure which OSes
>have this behavior -- but in practice it's true for enough of them that
>many people run into it.)
>
>> > b) If I have "ExitPolicyRejectPrivate 1" in my torrc, does that
>> > prevent such end-to-end encryption?
>
>No, because Tor looks at the address (1.2.3.4) and your exit policy is
>fine with it. It's only later, in the OS, that it gets switched over.

     Years ago, there was a bug that affected named that would sometimes
get hit if

nameserver 127.0.0.1

were in /etc/resolv.conf.  What would happen, IIRC, was that some program
on the localhost would query the name server via TCP instead of UDP, and
after named responded, the socket was never closed.  Because the
connection remained open, no other program could contact named on its TCP
port.  The workaround at that time was to put a different interface's IP
address into /etc/resolv.conf instead of 127.0.0.1.  That, of course,
added to traffic in both directions over that interface, but avoided use
TCP to localhost to reach named.
     As I understand what you are saying, that workaround would no longer
work in such a situation because something in the operating system (kernel,
pf, or whatever) would change the connection of the external address to
the loopback address anyway.
     I have to read up on writing pf rules anyway, so I'll keep my eye out
for how to write a rule to do that because I strongly doubt that the FreeBSD
kernel is going to rewrite addresses of its own volition.
>
>> >  If not, then does an
>> > "ExitPolicy reject *:*" at the end of my exit policy list count as
>> > "explicitly rejecting" such connections?
>
>Yes, because then your exit policy rejects 1.2.3.4, and Tor clients
>won't try to use you to exit to it.

     What I was asking there was, would the "reject *:*" at that point
reject the localhost connection?  But I see what you're saying now.  The
question remaining is how to accomplish the address translation (or even
just rerouting without translation) under FreeBSD.
>
>> > 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.
>
>Right, but note that you're going to have to bootstrap your first set of
>directory information somehow. There is no simple procedure currently,
>since we haven't seen the need for it yet.
>
     Okay.  Thanks for the better explanation of how the end-to-end stuff
is handled in tor.  On the premise that packets from a tor exit to an
external interface address on the tor exit server's hardware will be
readdressed/rerouted to localhost by some operating system component,
your explanation makes much more sense to me than the documentation alone.


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