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ò a...@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@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
