Alec Muffett <alec.muffett@gmail.com> writes:

On 15 Nov 2017 12:18, "Iain R. Learmonth" <irl@torproject.org> 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.

On 15 November 2017 at 05:35, Alec Muffett <alec.muffett@gmail.com> wrote:

Apologies, I am waiting for a train and don't have much bandwidth, so I will be brief:

1) There is no point in issuing <any header of any kind> to anyone unless they are accessing <website> via an exit node.

2) It's inefficient to issue the header upon every web access by every person in the world; when the header is only relevant to 1-in-a-few-thousand users, you will be imposing extra bandwidth cost upon the remaining 99.99...% -- which is unfair to them

Agreed (mostly). I could see use cases where users not accessing a website via Tor may wish to know an onionsite is available, but they are also the vast minority.

3) Therefore: the header should only be issued to people arriving via an exit node. The means of achieving this are

a) Location

b) Bending Alt-Svc to fit and breaking web standards

c) Creating an entirely new header

4) Location already works and does the right thing. Privacy International already use this and issue it to people who connect to their .ORG site from an Exit Node.

5) Bending Alt-Svc to fit, is pointless, because Location already works

6) Creating a new header? Given (4) and (5) above, the only potential material benefit of it that I can see would be to "promote Tor branding" - and (subjective opinion) this would actually harm the cause of Tor at all because it is *special*.

6 Rationale) The majority the "Dark Net" shade which had been thrown at Tor over the past 10 years has pivoted upon "needing special software to access", and creating (pardon me) a "special" header to onionify a fetch seems to be promoting the weirdness of Tor, again.

The required goal of redirection to the corresponding Onion site does not require anything more than a redirect, and - pardon me - but there are already 4x different kinds of redirects that are supported by the Location header (301, 302, 307, 308) with useful semantics. Why reinvent 4 wheels specially for Tor?

I think there are some additional things to gain by using a new header: Software that understands the header can handle it differently than Location. I think the notification bar and the 'Don't redirect me to the onionsite' options are pretty good UI things we should consider. They're actually not great UX, but it might be 'doing our part' to try and not confuse users about trusted browser chrome.[0] Users who _appear_ to be coming from an exit node but are not using Tor are not blackholed. How common is this? I've seen reports from users who do this. If I were in a position to, I would consider having exit node traffic 'blend into' more general non-exit traffic (like a university connection) just to make the political statement that "Tor traffic is internet traffic". Detecting exit nodes is error prone, as you point out. Some exit nodes have their traffic exit a different address than their listening port.[1] Location is really close to what we need, but it is limited in some ways. I'm still on the fence. [0] Except of course that notification bars are themselves spoofable chrome but lets ignore that for now... [1] Hey does Exonerator handle these? On 15 November 2017 at 07:38, Alec Muffett <alec.muffett@gmail.com> wrote:

I can see how you would think that, and I would kind-of agree, but at least this would be local and cheap. Perhaps instead of a magic protocol, it should be a REST API that's embedded in the local Tor daemon? That would be a really, REALLY common pattern for an enterprise to query.

This information should already be exposed via the Control Port, although there would be more work on behalf of the implementer to parse more information than desired and pare it down to what is needed. -tom

...

Detecting exit nodes is error prone, as you point out. Some exit nodes have their traffic exit a different address than their listening port. Hey does Exonerator handle these?

Right. It's not trivial for tor to figure out what exit relays are multi-homed -- at least not without actually establishing circuits and fetching content over each exit relay.

I just finished an exitmap scan and found 17 exit relays that exit from an IP address that is different from what's listed in the consensus:

This mode of operation, regardless of how it happens, is not in itself a problem, nor cause for alarm. In fact, the nature of these "exit IP different than ORPort" relays can and often does assist users in circumventing censorship... a fundamental use case of Tor. For instance, the arbitrary automated and blind blocking via dumb blocklists that prevent even such most basic user activity and human right to knowledge as simply reading websites via Tor. Such blocking examples can often be found here: https://trac.torproject.org/projects/tor/wiki/org/doc/ListOfServicesBlocking... It's also entirely up to the exit operator to determine if the third party non contractual / SLA exonerator service is of any particular use or benefit to them or not... perhaps they have other notary means, or are immune or not subject to any such legal or jurisdictional issues, for which it becomes moot. Similarly, realtime TorDNSEL and the like could be considered to be censorship enabling tools.

teor <teor2345@gmail.com> writes:

...

On 16 Nov 2017, at 00:38, Alec Muffett <alec.muffett@gmail.com> wrote:

...

I think it's important to point out that a Tor client is never guaranteed to hold a *definitive* consensus.

That's why I say "(mostly) definitive" in my text - my feeling is that a locally-held copy of the consensus to be queried is going to be on average of far higher quality, completeness, and non-stagnancy than something that one tries to scrape out of Onionoo every 15 minutes.

Please don't use a consensus or a tor client to check for exits for this purpose. It produces significant numbers of false negatives, because some exits use other IP addresses for their exit traffic.

I'm actually not a fan of Alec's idea, and I agree with you that there will be a significant number of false negatives, but it might be worth pointing out that IIUC false negatives are probably not so damaging in this use case, because it would result in users getting thrown to the normal website instead of the onion site, because the website didn't realize they are Tor users. So not much damage done there. False positives are a bit more damaging for reachability because it means that the website would throw normal users to the onion website which would fail, but that's not so likely (except if exit node operators surf from their exit node, or if an exit node IP is shared to other people).