[tor-dev] Alternatives to Tor Exit Enclaves

[Andrew Clausen]

Hi Arturo,

Do .exit addresses already do what you had in mind?  For example, if
you add "AllowDotExit 1" to your torrc, you can type an address like
this

http://thewebserver.exit/index.html

into your web browser.

It would be nice if this particular usage of .exit were allowed by
default (but the more dangerous anotherserver.anexitnode.exit still
remain disabled by default).

Cheers,
Andrew

On 18 April 2012 17:28, Arturo Filastò <art at baculo.org> wrote:
> The purpose of Exit Enclaves was to allow people running a website to
> make Tor users
> access it without ever leaving the Tor network. This leads to the
> clients having end-to-end
> encryption with the target destination.
>
> Even in previous version this had some issues, one of which was the fact
> that at the first
> connection the user would not be accessing the destination over a Tor
> circuit if the destination
> was provided in a hostname format (and not IP).
>
> The current stable version of Tor (0.2.2.x) still supports Exit
> enclaves. The new versions of Tor
> (> 0.2.3.x) use a new descriptor format (microdescriptors) allow relays
> to specify an Exit Enclave
> policy, but clients will not use it, therefore voiding the purpose of
> exit enclaving.
>
> I believe there is the need for something similar to Tor Exit Enclaving
> and the closest thing I see
> fit these requirements are Tor Encrypted Services
> (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-encrypted-services.txt).
>
> Encrypted Services (EC), are basically regular Tor Hidden Services, that
> do not provide anonymity
> for the server and gain a better performance because of this (they have
> a one-hop circuit
> to the RV and IP).
>
> The problem with making Encrypted services work to replace Exit Enclaves
> is that the client needs
> to have a way to understand that their destination is running also as an
> Encrypted Service.
>
> In this very high level overview I don't go into very much detail of how
> this system will actually
> work, but I hope it will prompt some discussion on the matter.
>
> I think this can be achieved mainly in 3 ways.
>
> 1) The client already knows all of the EC's
> 2) The client looks up if a destination is an EC when trying to connect
> to it
> 3) The final hop looks up if the destination is an EC
>
> These all have some drawbacks:
>
> In 1) the client needs to download the full list of EC's, therefore if
> the number of EC's get's
> very large it will take clients much more to bootstrap and they will
> need to store more data.
> The good thing of this though is that the speed of connections would be
> as fast as they
> are at the moment as it does not require any extra connections.
>
> In 2) the clients needs to complete an extra round-trip for every
> connection. I don't think
> this is a valid solution as it would degrade the quality of connections
> for every user.
>
> In 3) the final hop would do along side a normal A lookup for hostnames
> a CNAME lookup (
> or another special field). If it finds that such a lookup returns a
> .onion address instead of
> returning a RELAY_CONNECTED cell it will return a ENCRYPTED_SERVICE cell
> containing
> the .onion address of the target ES.
>
> The client will then cache this address and connect to it.
>
> This approach adds a little bit of overhead (since two DNS lookups need
> to be made),
> but it is still faster than 2).
>
> It suffers from the issue of the exit node could spoof the .onion
> address and redirect
> the user to a malicious .onion address. This is quite a tough problem
> that I am still
> unsure how it could be solved. If we have support for DNSSec this issue
> could be mitigated.
>
> I would love some feedback on this topic.
>
>
> - Art.
>
>
>
>
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev