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@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-enc...).
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.
- The client already knows all of the EC's
- 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev