[tor-talk] Exit enclaves

[Roger Dingledine]

On Tue, Dec 20, 2011 at 03:04:10PM +0100, tor wrote:
> Q1: Can the relay on the same node as the enclaved server also act as
>     a "normal" TOR exit node?

Yes.

> Q2: How is it ensured that requests to an enclaved server are always
>     routed through the TOR relay on the same machine?
> 
>     The TOR wiki page "https://trac.torproject.org/projects/tor/wiki
>     /doc/ExitEnclave" states that the relay becomes the 'preferred'
>     path to the enclaved server. That does not sound very strict. What
>     can be done to ensure this behaviour?
> 
> Let's assume that the enclaved server is a webserver. It is my
> understanding that if a user's browser requests a resource from an
> enclaved webserver, the existing 3-hop circuit (entry, middle and exit
> node) is extended towards the relay that hosts the enclaved server.

Correct. The problem comes when the user types in "www.cnn.com",
and there's a Tor relay running on the same IP address, but the user
doesn't know the IP address yet so she doesn't realize that there's an
exit enclave available.

The way it works then is that she makes a stream from some exit relay
to www.cnn.com, and as part of its "I connected successfully" answer
it includes the IP address it found for www.cnn.com. At that point the
Tor client will do the exit enclave thing for *future* streams -- which
could be good or bad, depending on the situation.

> Q3: Does the circuit extension also work if the URL of the enclaved
>     webserver entered in the user's browser is based on a domain name
>     rather than explicit IP addresses? It is my understanding that
>     TOR-based DNS resolution is not happening in the local proxy but on
>     the exit node; so how does the proxy know that the resource is on
>     an enclaved server and can initiate the circuit extension?

Exactly so. The Tor client only knows after the initial stream attempt.

You could do a 'mapaddress' line in your torrc, to tell the client
preemptively what IP address it should be. But that only works for the
clients that set it.

You could encourage all your users to connect to the server via IP
address. But that only works for the users who can handle the idea.

See
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt
for a start at an alternate design that should be more foolproof.

> Q4: Is it possible for someone that monitors the user traffic to detect
>     this circuit extension by any means, so that it is obvious that the
>     user is talking to an enclaved server? Are there any known attacks?

Probably.

We assume it's pretty easy, through timing analysis, to learn where
you are on the path. So if an exit relay is the third hop on the path,
and it is asked to extent to some other relay, the odds are good that
it's seeing an exit enclave attempt. (But that's ok, since the third
hop doesn't know about the user.)

It may also be possible to do a probabilistic attack at the entry
guard, or watching the client's local network. You look at the number of
round-trips of cells: three round-trips to establish a three-hop circuit,
then another round-trip for the begin cell and connected cell, then a
cell for the http get request, and a flood of cells in reply. It's unclear
how consistent the success of this attack would be, e.g. due to building
other preemptive circuits at the same time, doing directory fetches at the
same time, building 4-hop circuits for other reasons like hidden service
interaction, etc; but that's not at all the same as a security argument.

--Roger