Re: [tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header

[George Kadianakis <desnacked@xxxxxxxxxx>]

Alec Muffett <alec.muffett@xxxxxxxxx> writes:

> On 15 Nov 2017 12:18, "Iain R. Learmonth" <irl@xxxxxxxxxxxxxx> wrote:
>
> Is this not what TorDNSEL does?
> https://www.torproject.org/projects/tordnsel.html.en
>
>
> Hi Iain!
>

Hey Alec,

thanks for the feedback.

> That certainly sounds like it will give you the answer! But although it
> would give the right kind of answer, it is not what I am asking for.
>
> At the scale of websites like Facebook or the New York Times, a timely
> response is required for the purposes of rendering a page. The benefits of
> solving the problem at "enterprise" scale then trickle down to
> implementations of all sizes.
>
> Speaking as a programmer, it would be delightfully easy to make a DNS query
> and wait for a response to give you an answer... but then you have to send
> the query, wait for propagation, wait for a result, trust the result, debug
> cached versions of the results, leak the fact that all these lookups are
> going on, and so forth.
>
> This all adds adds up to latency and cost, as well as leaking metadata of
> your lookups; plus your local DNS administrator will hate you (cf: doing
> name resolution for every webpage fetch for writing Apache logs, is frowned
> upon.  Better to log the raw IP address and resolve it later if you need.
>
> On the other hand: if you are running a local Tor daemon, a copy of the
> entire consensus is held locally and is (basically) definitive.  You query
> it with near zero lookup latency, you get an instant response with no
> practical lag behind "real time", plus there are no men in the middle, and
> there is no unwanted metadata leakage.
>

I think it's important to point out that a Tor client is never
guaranteed to hold a *definitive* consensus. Currently Tor clients can
stay perfectly happy with a consensus that is up to 3 hours old, even if
they don't fetch the latest one (which gets made every hour).

In general, the Tor network does not have a definitive state at any
point, and different clients/relays can have different states at the
same time.

If we were to create "the definitive exit node oracle" we would need a
Tor client that polls the dirauths the second a new consensus comes out,
and maybe even then there could be desynchs. Perhaps it's worthwhile
doing such a thing, and maybe that's exactly what tordnsel is doing, but
it's something that can bring extra load to the dirauths and should not
be done in many instances.

Furthermore, you said that enterprises might be spooked out by
tor-specific "special" HTTP headers, but now we are discussing weird tor
modules that communicate with the Tor daemon to decide whether to
redirect clients, so it seems to me like an equally "special" Tor setup
for sysadmins.
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev