Alternatives to Tor Exit Enclaves
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. 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.
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.
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
On 4/18/12 5:33 PM, Andrew Clausen wrote:
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
No, .exit notation is a bad idea because it allows people to force you to exit through a particular exit node of their choosing. For example I can place a <img src=""> tag on a website and de-anonymize every user by getting them to go through my address. - Art.
Hi Arturo, On 18 April 2012 17:47, Arturo Filastò <art@baculo.org> wrote:
On 4/18/12 5:33 PM, Andrew Clausen wrote:
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
No, .exit notation is a bad idea because it allows people to force you to exit through a particular exit node of their choosing.
I suppose this is true, according to the spec. (When I tested this out, the implementation seemed to match my proposal below rather than the spec. I haven't had a chance to look at it.) However, it would be easy to change Tor slightly. If Tor used four ORs rather than three with .exit addresses, then there would be no problem. The only difference between using "http://myserver.exit" rather than "https://myserver.com" would be that the last hop would use the Tor protocol rather than HTTP.
For example I can place a <img src=""> tag on a website and de-anonymize every user by getting them to go through my address.
The situation for <img src="http://myserver.exit"> would be no worse than for <img src="http://myserver.com"> Cheers, Andrew
Arturo Filastò <art@baculo.org> writes:
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.
Probably I'm missing something obvious, but can't you provide something more-or-less equivalent with a self-signed certificate and HTTPS to access your hidden service? -- mike
On Wed, 18 Apr 2012 17:28:42 -0400 Arturo Filastò <art@baculo.org> wrote:
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.
Is there a plan to re-enable clients to use exit enclaves? -- Andrew http://tpo.is/contact pgp 0x6B4D6475
On 4/19/12 3:42 AM, Andrew Lewman wrote:
On Wed, 18 Apr 2012 17:28:42 -0400 Arturo Filastò <art@baculo.org> wrote:
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. Is there a plan to re-enable clients to use exit enclaves?
The overall consensus that I got from discussing this in IRC is that Exit Enclaves where never thought of very well and they already did not have all the properties that we wanted. Re-enabling clients to use exit enclaves requires changes to the microdescriptor format, and since they have issues we should not encourage their use. - Art.
participants (4)
-
Andrew Clausen -
Andrew Lewman -
Arturo Filastò -
Mike Warren