Discussion:
[tor-dev] UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
George Kadianakis
2017-11-14 12:51:55 UTC
Permalink
UX improvement proposal: Onion auto-redirects using Alt-Svc HTTP header
========================================================================

1. Motivation:

Lots of high-profile websites have onion addresses these days (e.g. Tor ,
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
some confusion examples:
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.

Ideally there would be a consistent way for websites to inform their users
about their onion counterpart. This would provide the following positives:
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)

This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.

Also see Tor ticket #21952 for more discussion on this:
https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

Websites use the Alt-Svc HTTP header to specify their onion counterpart:
http://httpwg.org/http-extensions/alt-svc.html

The Tor Browser intercepts that header (if any) and auto-redirects the user
to the onion site. Tor Browser only does so if the header is served over HTTPS.

(That's it.)

3. Improvements

3.1. User education through notifications

To minimize the probability of users freaking out about auto-redirects Tor
Browser could inform the user that the auto-redirect is happening. This
could happen with a small notification bar [*] below the URL bar informing
users that "Tor Browser is auto-redirecting you to the secure onion site".

The notification bar could also have a question mark button that provides
the user with additional information on the merits of onion sites and why
they should like them.

[*]: like this one: Loading Image...

3.2. Auto-redirects too intrusive? Make them optional.

If we think that auto redirects are too intrusive, we should consider making
them optional, or letting the website specify the desired behavior.

If a website wants to specify an onion address but doesn't like
auto-redirects, it could specify that as part of Alt-Svc and we could still
inform the user that an onion is available using a notification bar again.

4. Drawbacks

This proposal is far from the perfect solution of course. Here are a few
reasons why:

4.1. Auto-redirects are scary

Novice users or paranoid users might freak out with auto-redirects since
it's unexpected. They might think they are under attack or they got hacked.

An argument against that is that we are already using HTTPS-everywhere which
is basically a redirection layer, and while its redirection technique is
simpler, sometimes the derivative URL is not similar to the original URL,
and we still don't see people freaking out. I think that's because people
trust Tor Browser to do the right thing. Combining this knowledge with
section 3.1 might solve this problem.

4.2. No security/performance benefits

While we could come up with auto-redirect proposals that provide security
and performance benefits, this proposal does not actually provide any of
those.

As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
since we first need to connect to the website, get its headers, and then
also connect to the onion.

Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.

4.3. Alt-Svc does not do exactly what we want

I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
in the location bar, document.location or any other indication of where the
resource is; this is a “layer below” the URL.". IIUC, this is not exactly
what we want because users will not notice the onion address, they will not
get the user education part of the proposal and their connection will still
be slowed down.

I think we could perhaps change this in Tor Browser so that it rewrites the
onion address to make it clear to people that they are now surfing the
onionspace.

[*]: https://www.mnot.net/blog/2016/03/09/alt-svc

5. The future

As I said this is just a simple proposal to introduce the auto-redirect
concept to people, and also to help some sysadmins who are currently coming
up with weird ways to inform people about their onions. It's not the best
way to do this, but it's definitely one of the simplest ways.

In the future we could implement with more advanced auto-redirect proposals like:

a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
autoredirects for us (performance benefits, and security benefits under many
threat models).

b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
by comment:42 in #21952.

But both of the designs above require non-trivial engineering/policy work
and would still confuse people. So I think starting with a simple approach
that will educate users and then moving to more advanced designs is a more
normative way to go.

======================================================================

Let me know what you think :)

(Should this be part of torspec?)
teor
2017-11-14 17:25:09 UTC
Permalink
Post by George Kadianakis
3.2. Auto-redirects too intrusive? Make them optional.
If we think that auto redirects are too intrusive, we should consider making
them optional, or letting the website specify the desired behavior.
If a website wants to specify an onion address but doesn't like
auto-redirects, it could specify that as part of Alt-Svc and we could still
inform the user that an onion is available using a notification bar again.
Inform the user that the onion address is available.

Make the default behaviour *not* to redirect (it's not faster, it's not more
secure, and it's surprising). But I'd be willing to compromise here, by
letting the site specify an initial default, and having the Tor Browser default
be whatever.

Let *the user* control the behaviour via the notification bar, and maybe
allow them to set a session default.
(This won't be persistent, for disk leak reasons.)
Post by George Kadianakis
4. Drawbacks
You missed the biggest one:

If the onion site is down, the user will be redirected to the downed site.
(I've used onion site redirects with this issue, it's really annoying.)
Similarly, if a feature is broken on the onion site, the user will be
redirected to a site they can't use.

Or if the user simply wants to use the non-onion site for some reason
(maybe they want a link they can share with their non-onion friends,
or maybe they don't want to reveal they're using Tor Browser).

Users *must* have a way to disable the redirect on every redirect.

T
Tom Ritter
2017-11-14 21:31:43 UTC
Permalink
I am a big proponent of websites advertising .onions in their Alt-Srv.
Post by George Kadianakis
3.1. User education through notifications
To minimize the probability of users freaking out about auto-redirects Tor
Browser could inform the user that the auto-redirect is happening. This
could happen with a small notification bar [*] below the URL bar informing
users that "Tor Browser is auto-redirecting you to the secure onion site".
The notification bar could also have a question mark button that provides
the user with additional information on the merits of onion sites and why
they should like them.
[*]: like this one: http://www.topdreamweaverextensions.com/UserFiles/Image/firefox-bar.jpg
I think this is a good idea, and would be the best place to put the
"Never show me this again" option.
Post by George Kadianakis
4.2. No security/performance benefits
While we could come up with auto-redirect proposals that provide security
and performance benefits, this proposal does not actually provide any of
those.
As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
since we first need to connect to the website, get its headers, and then
also connect to the onion.
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.
I envision a future Onion Everywhere extension like HTTPS Everywhere
that works similar to the HSTS preload list. Crawlers validate a
websites intention to be in the Onion Everywhere extension, and we
cache the Alt-Srv information so it is used on first load.
Post by George Kadianakis
4.3. Alt-Svc does not do exactly what we want
I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
in the location bar, document.location or any other indication of where the
resource is; this is a “layer below” the URL.". IIUC, this is not exactly
what we want because users will not notice the onion address, they will not
get the user education part of the proposal and their connection will still
be slowed down.
I think we could perhaps change this in Tor Browser so that it rewrites the
onion address to make it clear to people that they are now surfing the
onionspace.
[*]: https://www.mnot.net/blog/2016/03/09/alt-svc
I am a big opponent of changing the semantics of Alt-Srv.

We'd have to change the semantics to only do redirection for onion
domains. We'd also have to figure out how to handle cases where the
onion lives alongside non-onion (which takes precedence?) We'd also
have to maintain and carry this patch ourselves because it's pretty
antithetical to the very intent of the header and I doubt the
networking team at Mozilla would be interested in maintaining it.

Besides those issues, it also eliminates Alt-Srv as a working option
to something *else* websites may want: to silently redirect users to
their .onion _without_ the possibility of confusion for the user by
changing the address bar. I think Alt-Srv is an option for partial
petname support in TB.

There is a perfectly functioning mechanism for redirecting users: the
Location header. It does a lot of what you want: including temporary
or persistent redirects, updating the addess bar. Obviously it doesn't
work for all users, most don't know what .onion is, so Facebook isn't
going to deploy a .onion Location redirect even if they attempted to
detect TB users.

But they could send a new Onion-Redirect header that is recognized and
processed (with a notification bar) by any UA that supports Tor and
wants to implement it. This header would have a viable path to uplift,
support in extensions, and even standardization. Onion Everywhere can
preload these headers too.
Post by George Kadianakis
Post by George Kadianakis
4. Drawbacks
If the onion site is down, the user will be redirected to the downed site.
(I've used onion site redirects with this issue, it's really annoying.)
Similarly, if a feature is broken on the onion site, the user will be
redirected to a site they can't use.
Or if the user simply wants to use the non-onion site for some reason
(maybe they want a link they can share with their non-onion friends,
or maybe they don't want to reveal they're using Tor Browser).
Users *must* have a way to disable the redirect on every redirect.
Right now, I don't agree with this. (I reserve the right to change my
mind.) Websites can already redirect users to broken links through
mistakes. Why is "my onion site is not running" a scenario we want to
code around but "my subdomain is not running" is not? If a website
wants to redirect users they should be responsible enough to monitor
the uptime of their onion domain and keep it running. Maybe we need
better tooling for that, but that's different from saying we need to
put the onus on users for webmasters failing to keep their sites
running.

-tom
George Kadianakis
2017-11-15 10:09:44 UTC
Permalink
Post by Tom Ritter
I am a big proponent of websites advertising .onions in their Alt-Srv.
Post by George Kadianakis
4.2. No security/performance benefits
While we could come up with auto-redirect proposals that provide security
and performance benefits, this proposal does not actually provide any of
those.
As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
since we first need to connect to the website, get its headers, and then
also connect to the onion.
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.
I envision a future Onion Everywhere extension like HTTPS Everywhere
that works similar to the HSTS preload list. Crawlers validate a
websites intention to be in the Onion Everywhere extension, and we
cache the Alt-Srv information so it is used on first load.
Yep, that's yet another cool way to do this.
Post by Tom Ritter
Post by George Kadianakis
4.3. Alt-Svc does not do exactly what we want
I read in a blog post [*] that using Alt-Svc header "doesn’t change the URL
in the location bar, document.location or any other indication of where the
resource is; this is a “layer below” the URL.". IIUC, this is not exactly
what we want because users will not notice the onion address, they will not
get the user education part of the proposal and their connection will still
be slowed down.
I think we could perhaps change this in Tor Browser so that it rewrites the
onion address to make it clear to people that they are now surfing the
onionspace.
[*]: https://www.mnot.net/blog/2016/03/09/alt-svc
I am a big opponent of changing the semantics of Alt-Srv.
We'd have to change the semantics to only do redirection for onion
domains. We'd also have to figure out how to handle cases where the
onion lives alongside non-onion (which takes precedence?) We'd also
have to maintain and carry this patch ourselves because it's pretty
antithetical to the very intent of the header and I doubt the
networking team at Mozilla would be interested in maintaining it.
Besides those issues, it also eliminates Alt-Srv as a working option
to something *else* websites may want: to silently redirect users to
their .onion _without_ the possibility of confusion for the user by
changing the address bar. I think Alt-Srv is an option for partial
petname support in TB.
There is a perfectly functioning mechanism for redirecting users: the
Location header. It does a lot of what you want: including temporary
or persistent redirects, updating the addess bar. Obviously it doesn't
work for all users, most don't know what .onion is, so Facebook isn't
going to deploy a .onion Location redirect even if they attempted to
detect TB users.
But they could send a new Onion-Redirect header that is recognized and
processed (with a notification bar) by any UA that supports Tor and
wants to implement it. This header would have a viable path to uplift,
support in extensions, and even standardization. Onion Everywhere can
preload these headers too.
Agreed, the semantics of Alt-Svc are not what we want, and it's probably
not a good idea to change it from an engineering/policy perspective.

Establishing our own header, with the same semantics as Location, seems
to be a cleaner way to approach this.

When I find some time (hopefully this or next week) I will fix up the
proposal based on received feedback.
Post by Tom Ritter
Post by George Kadianakis
Post by George Kadianakis
4. Drawbacks
If the onion site is down, the user will be redirected to the downed site.
(I've used onion site redirects with this issue, it's really annoying.)
Similarly, if a feature is broken on the onion site, the user will be
redirected to a site they can't use.
Or if the user simply wants to use the non-onion site for some reason
(maybe they want a link they can share with their non-onion friends,
or maybe they don't want to reveal they're using Tor Browser).
Users *must* have a way to disable the redirect on every redirect.
Right now, I don't agree with this. (I reserve the right to change my
mind.) Websites can already redirect users to broken links through
mistakes. Why is "my onion site is not running" a scenario we want to
code around but "my subdomain is not running" is not? If a website
wants to redirect users they should be responsible enough to monitor
the uptime of their onion domain and keep it running. Maybe we need
better tooling for that, but that's different from saying we need to
put the onus on users for webmasters failing to keep their sites
running.
Agreed. As long as onion services provide a consistent service,
sysadmins should be responsible for maintaining the mapping and
availability of their services.
Alec Muffett
2017-11-15 11:35:06 UTC
Permalink
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

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?

7) Story: when I was implementing the Facebook onion, I built infra to
support such (eventual) redirection and/or exit-node-usage tracking. Hit "
facebook.com/si/proxy/" from Tor/NonTor to see it in action. The most
challenging thing for me was to get a reliable and cheap way to look-up,
locally, quickly, cheaply and reliably, whether a given IP address
corresponded to an exit node. The closest that I could get to that idea was
to scrape Onionoo every so often and to cache the results into a
distributed, almost-memcache-like table for the entire site. ie: squillions
of machines. This mechanism suffers from all the obvious flaws, notably
Onionoo crashes and/or "lag" behind the state of the consensus.

8) So, to pass concrete advice on the basis of experience: rather than
pursue novel headers and reinvent a bunch of established, widely-understood
web redirection technologies, I would ask that Tor focus its efforts
instead upon providing a service - perhaps a listener service embedded in
little-t tor as an enable-able service akin to SOCKSListener - which can
accept a request from <cidr-subnetmask>, receive an newline-terminated IP
address, and return a set of flags associated with that IP (exit node,
relay, whatever) - or "none" where the IP is not part of the tor network.
Riff on this protocol as you see fit.

This would mean more people running more tor daemons in more datacentres
(and possibly configuring some of them as relays) - using this lookup
service to establish quickly whether $CLIENT_ADDR is an exit node or not,
and whether it should be issued "308 Permanent Redirect With Same Method"

I think this is a better goal for Tor to be pursuing. What do you think?

- alec
Iain R. Learmonth
2017-11-15 12:17:32 UTC
Permalink
Hi,
Post by Alec Muffett
8) So, to pass concrete advice on the basis of experience: rather than
pursue novel headers and reinvent a bunch of established,
widely-understood web redirection technologies, I would ask that Tor
focus its efforts instead upon providing a service - perhaps a listener
service embedded in little-t tor as an enable-able service akin to
SOCKSListener - which can accept a request from <cidr-subnetmask>,
receive an newline-terminated IP address, and return a set of flags
associated with that IP (exit node, relay, whatever) - or "none" where
the IP is not part of the tor network.  Riff on this protocol as you see
fit.
Is this not what TorDNSEL does?

https://www.torproject.org/projects/tordnsel.html.en

Thanks,
Iain.
Alec Muffett
2017-11-15 13:11:06 UTC
Permalink
On 15 Nov 2017 12:18, "Iain R. Learmonth" <***@torproject.org> wrote:

Is this not what TorDNSEL does?
https://www.torproject.org/projects/tordnsel.html.en


Hi Iain!

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.

If the Tor daemon is on the local machine, then the lookup cost is
near-zero, and - hey! - you are encouraging more people to run more tor
daemons, which (as above) has to be a good thing.

So: the results are very close to what TorDNSEL provides, but what I seek
is something with different and better latency, security, reliability and
privacy qualities than TorDNSEL offers.

- alec
George Kadianakis
2017-11-15 13:31:10 UTC
Permalink
Post by Iain R. Learmonth
Is this not what TorDNSEL does?
https://www.torproject.org/projects/tordnsel.html.en
Hi Iain!
Hey Alec,

thanks for the feedback.
Post by Iain R. Learmonth
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.
Alec Muffett
2017-11-15 13:38:33 UTC
Permalink
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.

True "definitiveness" can wait. A solution which does not require treading
beyond the local area network for a "good enough" result, is a sufficient
90+% solution :-)


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,


So let's not do that, then.


Furthermore, you said that enterprises might be spooked out by
tor-specific "special" HTTP headers,


Yes.


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.


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.

How about that?

- alec
Tom Ritter
2017-11-15 16:03:39 UTC
Permalink
Apologies, I am waiting for a train and don't have much bandwidth, so I will
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?
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
Philipp Winter
2017-11-15 16:27:56 UTC
Permalink
Post by Tom Ritter
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]
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:

193.171.202.146 -> 193.171.202.150 for <https://atlas.torproject.org/#details/01A9258A46E97FF8B2CAC7910577862C14F2C524>
104.223.123.99 -> 104.223.123.98 for <https://atlas.torproject.org/#details/D4010FAD096CFB59278015F711776D8CCB2735EC>
87.118.83.3 -> 87.118.82.3 for <https://atlas.torproject.org/#details/A8EA2EBB29B0BA4472F26A04A342967FF06CC104>
89.31.57.58 -> 89.31.57.5 for <https://atlas.torproject.org/#details/7DD29A65C370B86B5BE706EA3B1417745714C8AF>
37.187.105.104 -> 196.54.55.14 for <https://atlas.torproject.org/#details/91824956DFA430C071BF6B94B623DF10931D1D40>
77.247.181.164 -> 77.247.181.162 for <https://atlas.torproject.org/#details/204DFD2A2C6A0DC1FA0EACB495218E0B661704FD>
198.211.103.26 -> 185.165.169.23 for <https://atlas.torproject.org/#details/E56E6976ED9C6B72528ECEDA6C6CEEAC767FA26C>
52.15.62.13 -> 69.181.127.85 for <https://atlas.torproject.org/#details/833B03789A2A98C6B53D792156FEA3D2E1ECE967>
138.197.4.77 -> 163.172.45.46 for <https://atlas.torproject.org/#details/D5D6DBED4BEB90DB089AC1E57EA3A13B9B8AA769>
52.15.62.13 -> 104.132.0.104 for <https://atlas.torproject.org/#details/BF0E33F3897A2109D03DAA2F73AAF8ED25FB6F4D>
31.185.27.203 -> 31.185.27.201 for <https://atlas.torproject.org/#details/5D263037FC175596B3A344132B0B755EB8FB1D1C>
104.223.123.101 -> 104.223.123.98 for <https://atlas.torproject.org/#details/02A627FA195809A3ABE031B7864CCA7A310F1D44>
77.247.181.166 -> 77.247.181.162 for <https://atlas.torproject.org/#details/77131D7E2EC1CA9B8D737502256DA9103599CE51>
149.56.223.240 -> 149.56.223.241 for <https://atlas.torproject.org/#details/B6718125C43ECA2E5011B3C681BB6638617A9686>
88.190.118.95 -> 94.23.201.80 for <https://atlas.torproject.org/#details/8C8F0AA30AD7819F16BBD530586CFE58EBA39948>
192.241.79.175 -> 192.241.79.178 for <https://atlas.torproject.org/#details/DA6CB6C05F4A404184FC3A85FDB83F935C6620DC>
143.106.60.70 -> 193.15.16.4 for <https://atlas.torproject.org/#details/6BF913C31A47E020637121014DB2AFE0877BD31B>
grarpamp
2017-11-18 23:08:11 UTC
Permalink
Post by Philipp Winter
Post by Tom Ritter
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
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/ListOfServicesBlockingTor

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
2017-11-16 03:23:02 UTC
Permalink
Post by George Kadianakis
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.

Using Onionoo or TorDNSEL reduces your false negatives, because it
pulls data from Exitmap to populate exit_addresses. (Tor clients do
not pull data from Exitmap, and that data is not in the consensus.)
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]
...
[1] Hey does Exonerator handle these?
Exonerator uses data from Exitmap, which queries a service through each
exit to discover the address(es) the exit uses to send client requests
to websites.

The list is updated every 24 hours.
So there's really no need to scrape OnionOO every 15 minutes.
Post by George Kadianakis
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.
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.
You can download the set of exit addresses every 24 hours, and write a
small tool that implements a REST API to query it:

https://check.torproject.org/exit-addresses

In fact, you could even adapt the "check" service to your needs, if it
doesn't do what you want already:

https://gitweb.torproject.org/check.git

Is this the kind of JSON reply you would want?

https://check.torproject.org/api/ip

{"IsTor":true,"IP":"176.10.104.243"}

Or for the interactive version, see:

https://check.torproject.org/cgi-bin/TorBulkExitList.py

(And if you supply a destination port, it's more accurate, because it
checks exit policies as well.)

T

--
Tim / teor

PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
------------------------------------------------------------------------
George Kadianakis
2017-11-17 20:33:05 UTC
Permalink
Post by teor
Post by George Kadianakis
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).
Philipp Winter
2017-11-15 16:16:44 UTC
Permalink
Post by George Kadianakis
Let me know what you think :)
Section 9.4 in the Alt-Svc draft talks about abusing the header for
tracking. In particular, a malicious website could give each Tor user
a unique onion domain to track their activity. That's particularly
problematic if the "persist" flag is used in the Alt-Svc header.

Granted, malicious websites can already do that to an extent by serving
unique onion domains on each page load, but we should still keep this
issue in mind.
George Kadianakis
2017-12-08 15:06:01 UTC
Permalink
As discussed in this mailing list and in IRC, I'm posting a subsequent
version of this proposal. Basic improvements:
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
antonella's mockup: Loading Image...



========================================================================
UX improvement proposal: Onion redirects using Onion-Location HTTP header
========================================================================

1. Motivation:

Lots of high-profile websites have onion addresses these days (e.g. Tor ,
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
some confusion examples:
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.

Ideally there would be a consistent way for websites to inform their users
about their onion counterpart. This would provide the following positives:
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)

This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.

Also see Tor ticket #21952 for more discussion on this:
https://trac.torproject.org/projects/tor/ticket/21952

2. Proposal

We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header. Websites can use the
Onion-Location HTTP header to specify their onion counterpart, in the same
way that they would use the Location header.

The Tor Browser intercepts the Onion-Location header (if any) and informs
the user of the existense of the onion site, giving them the option to visit
it. Tor Browser only does so if the header is served over HTTPS.

Browsers that don't support Tor SHOULD ignore the Onion-Location header.

3. Improvements

4. Drawbacks

4.1. No security/performance benefits

While we could come up with onion redirection proposals that provide
security and performance benefits, this proposal does not actually provide
any of those.

As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
since we first need to connect to the website, get its headers, and then
also connect to the onion.

Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.

4.2. Defining new HTTP headers is not the best idea

This proposal defines a new non-standard HTTP header. This is not great
because it makes Tor into a "special" thing that needs to be supported with
special headers. However, the fact that it's a new HTTP header that only
works for Tor is a positive thing since it means that non-Tor browsers will
just ignore it.

Furthermore, another drawback is that this HTTP header will increase the
bandwidth needlessly if it's also served to non-Tor clients. Hence websites
with lots of client traffic are encouraged to use tools that detect Tor
users and only serve the header to them (e.g. tordnsel).

5. The future

As previously discussed, this is just a simple proposal to introduce the
redirection concept to people, and also to help some sysadmins who are
currently coming up with weird ways to inform people about their
onions. It's not the best way to do this, but it's definitely one of the
simplest ways.

In the future we could implement with more advanced auto-redirect proposals like:

a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
autoredirects for us (performance benefits, and security benefits under many
threat models).

b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
by comment:42 in #21952.

But both of the designs above require non-trivial engineering/policy work
and would still confuse people. So I think starting with a simple approach
that will educate users and then moving to more advanced designs is a more
normative way to go.

======================================================================
Tom Ritter
2017-12-08 16:27:41 UTC
Permalink
Post by George Kadianakis
As discussed in this mailing list and in IRC, I'm posting a subsequent
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
========================================================================
UX improvement proposal: Onion redirects using Onion-Location HTTP header
========================================================================
Lots of high-profile websites have onion addresses these days (e.g. Tor ,
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.
Ideally there would be a consistent way for websites to inform their users
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)
This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.
https://trac.torproject.org/projects/tor/ticket/21952
2. Proposal
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header.
For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2
Post by George Kadianakis
Websites can use the
Onion-Location HTTP header to specify their onion counterpart, in the same
way that they would use the Location header.
The Tor Browser intercepts the Onion-Location header (if any) and informs
the user of the existense of the onion site, giving them the option to visit
it. Tor Browser only does so if the header is served over HTTPS.
Browsers that don't support Tor SHOULD ignore the Onion-Location header.
3. Improvements
4. Drawbacks
4.1. No security/performance benefits
While we could come up with onion redirection proposals that provide
security and performance benefits, this proposal does not actually provide
any of those.
As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
since we first need to connect to the website, get its headers, and then
also connect to the onion.
I would specifically call out that the user has provided any
identifying information (cookies) that may be present, as well as
opened themselves to any possible browser-based attack vector served
by the target domain.
Post by George Kadianakis
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
help those websites and also pave the way forward for future auto-redirect
techniques.
4.2. Defining new HTTP headers is not the best idea
This proposal defines a new non-standard HTTP header. This is not great
because it makes Tor into a "special" thing that needs to be supported with
special headers. However, the fact that it's a new HTTP header that only
works for Tor is a positive thing since it means that non-Tor browsers will
just ignore it.
Furthermore, another drawback is that this HTTP header will increase the
bandwidth needlessly if it's also served to non-Tor clients. Hence websites
with lots of client traffic are encouraged to use tools that detect Tor
users and only serve the header to them (e.g. tordnsel).
I would talk about how users could experience false positives and
false negatives if this mechanism is used.



I think it is also worth addressing that this does not stop sysadmins
from (trying to) detect tor users, and send the onion address in the
Location header, thus triggering a non-prompting redirect. But that
they should consider the potential user confusion of being redirected
to an odd looking domain in such a scenario. And state that this
mechanism is designed to provide a browser-supported option to
consistently offer an onion service in a hopefully less-confusing way.

-tom
Post by George Kadianakis
5. The future
As previously discussed, this is just a simple proposal to introduce the
redirection concept to people, and also to help some sysadmins who are
currently coming up with weird ways to inform people about their
onions. It's not the best way to do this, but it's definitely one of the
simplest ways.
a) Have a "domains to onions" map into HTTPS-everywhere and have it do the
autoredirects for us (performance benefits, and security benefits under many
threat models).
b) Bake onion addresses into SSL certificates and Let's Encrypt as suggested
by comment:42 in #21952.
But both of the designs above require non-trivial engineering/policy work
and would still confuse people. So I think starting with a simple approach
that will educate users and then moving to more advanced designs is a more
normative way to go.
======================================================================
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
teor
2017-12-08 21:48:16 UTC
Permalink
Post by Tom Ritter
Post by George Kadianakis
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header.
For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2
Because this is a non-standard header, does it need to be spelled:
"X-Onion-Location"?

T
Tom Ritter
2017-12-08 21:49:46 UTC
Permalink
Post by teor
Post by Tom Ritter
Post by George Kadianakis
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header.
For reference, this is https://tools.ietf.org/html/rfc7231#section-7.1.2
"X-Onion-Location"?
Nope =)
https://tools.ietf.org/html/rfc6648

-tom
Georg Koppen
2017-12-14 14:28:00 UTC
Permalink
Post by George Kadianakis
As discussed in this mailing list and in IRC, I'm posting a subsequent
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).
Post by George Kadianakis
========================================================================
UX improvement proposal: Onion redirects using Onion-Location HTTP header
========================================================================
Lots of high-profile websites have onion addresses these days (e.g. Tor ,
Tor,
Post by George Kadianakis
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.
Ideally there would be a consistent way for websites to inform their users
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)
This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.
https://trac.torproject.org/projects/tor/ticket/21952
2. Proposal
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header. Websites can use the
Onion-Location HTTP header to specify their onion counterpart, in the same
way that they would use the Location header.
The Tor Browser intercepts the Onion-Location header (if any) and informs
the user of the existense of the onion site, giving them the option to visit
s/existense/existence/
Post by George Kadianakis
it. Tor Browser only does so if the header is served over HTTPS.
Browsers that don't support Tor SHOULD ignore the Onion-Location header.
3. Improvements
Did you plan to write anything here? I guess there are at least UX
improvements to the ad-hoc things you mentioned at the beginning of the
proposal.
Post by George Kadianakis
4. Drawbacks
4.1. No security/performance benefits
While we could come up with onion redirection proposals that provide
security and performance benefits, this proposal does not actually provide
any of those.
As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
s/its/their/
Post by George Kadianakis
since we first need to connect to the website, get its headers, and then
also connect to the onion.
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
s/abou/about/
Post by George Kadianakis
help those websites and also pave the way forward for future auto-redirect
techniques.
4.2. Defining new HTTP headers is not the best idea
This proposal defines a new non-standard HTTP header. This is not great
because it makes Tor into a "special" thing that needs to be supported with
special headers. However, the fact that it's a new HTTP header that only
works for Tor is a positive thing since it means that non-Tor browsers will
just ignore it.
Furthermore, another drawback is that this HTTP header will increase the
bandwidth needlessly if it's also served to non-Tor clients. Hence websites
with lots of client traffic are encouraged to use tools that detect Tor
users and only serve the header to them (e.g. tordnsel).
5. The future
As previously discussed, this is just a simple proposal to introduce the
redirection concept to people, and also to help some sysadmins who are
currently coming up with weird ways to inform people about their
onions. It's not the best way to do this, but it's definitely one of the
simplest ways.
s/with// maybe?

[snip]

Georg
George Kadianakis
2018-02-02 10:32:36 UTC
Permalink
[ text/plain ]
Post by George Kadianakis
As discussed in this mailing list and in IRC, I'm posting a subsequent
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).
Hello,

pushed another commit to the onion-location branch in my repo for
addressing the concerns in GeKo's email:
https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location&id=14fc750e3afcd759f4235ab955535a07eed24286

I was not sure what other stuff to put in section 2 but please let me
know if you don't feel fullfiled with the current ones!!!

Also, I wiped out the improvements section because i was not sure what
to put there.

As a side thing, I found this extension which does the bottombar part of
this proposal, but it gets the redirection list from a local file
instead of an HTTP header: https://github.com/Someguy123/HiddenEverywhere

Cheers!
Post by George Kadianakis
========================================================================
UX improvement proposal: Onion redirects using Onion-Location HTTP header
========================================================================
Lots of high-profile websites have onion addresses these days (e.g. Tor ,
Tor,
Post by George Kadianakis
NYT, blockchain, ProPublica). All those websites seem confused on what's
the right way to inform their users about their onion addresses. Here are
a) torproject.org does not even advertise their onion address to Tor users (!!!)
b) blockchain.info throws an ugly ASCII page to Tor users mentioning their onion
address and completely wrecking the UX (loses URL params, etc.)
c) ProPublica has a "Browse via Tor" section which redirects to the onion site.
Ideally there would be a consistent way for websites to inform their users
+ Tor users would use onions more often. That's important for user
education and user perception, and also to partially dispell the darkweb myth.
+ Website operators wouldn't have to come up with ad-hoc ways to advertise
their onion services, which sometimes results in complete breakage of
the user experience (particularly with blockchain)
This proposal specifies a simple way forward here that's far from perfect,
but can still provide benefits and also improve user-education around onions
so that in the future we could employ more advanced techniques.
https://trac.torproject.org/projects/tor/ticket/21952
2. Proposal
We introduce a new HTTP header called "Onion-Location" with the exact same
restrictions and semantics as the Location HTTP header. Websites can use the
Onion-Location HTTP header to specify their onion counterpart, in the same
way that they would use the Location header.
The Tor Browser intercepts the Onion-Location header (if any) and informs
the user of the existense of the onion site, giving them the option to visit
s/existense/existence/
Post by George Kadianakis
it. Tor Browser only does so if the header is served over HTTPS.
Browsers that don't support Tor SHOULD ignore the Onion-Location header.
3. Improvements
Did you plan to write anything here? I guess there are at least UX
improvements to the ad-hoc things you mentioned at the beginning of the
proposal.
Post by George Kadianakis
4. Drawbacks
4.1. No security/performance benefits
While we could come up with onion redirection proposals that provide
security and performance benefits, this proposal does not actually provide
any of those.
As a matter of fact, the security remains the same as connecting to normal
websites (since we trust its HTTP headers), and the performance gets worse
s/its/their/
Post by George Kadianakis
since we first need to connect to the website, get its headers, and then
also connect to the onion.
Still _all_ the website approaches mentioned in the "Motivation" section
suffer from the above drawbacks, and sysadmins still come up with ad-hoc
ways to inform users abou their onions. So this simple proposal will still
s/abou/about/
Post by George Kadianakis
help those websites and also pave the way forward for future auto-redirect
techniques.
4.2. Defining new HTTP headers is not the best idea
This proposal defines a new non-standard HTTP header. This is not great
because it makes Tor into a "special" thing that needs to be supported with
special headers. However, the fact that it's a new HTTP header that only
works for Tor is a positive thing since it means that non-Tor browsers will
just ignore it.
Furthermore, another drawback is that this HTTP header will increase the
bandwidth needlessly if it's also served to non-Tor clients. Hence websites
with lots of client traffic are encouraged to use tools that detect Tor
users and only serve the header to them (e.g. tordnsel).
5. The future
As previously discussed, this is just a simple proposal to introduce the
redirection concept to people, and also to help some sysadmins who are
currently coming up with weird ways to inform people about their
onions. It's not the best way to do this, but it's definitely one of the
simplest ways.
s/with// maybe?
[snip]
Georg
[ signature.asc: application/pgp-signature ]
[ text/plain ]
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Iain Learmonth
2018-07-07 18:07:06 UTC
Permalink
Hi,

I've had a go at implementing this for my personal blog. Here are some
Post by George Kadianakis
We introduce a new HTTP header called "Onion-Location"
with the exact same restrictions and semantics as the
Location HTTP header. Websites can use the Onion-Location
HTTP header to specify their onion counterpart, in the
same way that they would use the Location header.
Onion-Location: http://vwc43ag5jyewlfgf.onion
This example is perhaps not the best example. I tried to get things
working with the Healthy Onions add-on, but found that the developer had
interpreted this to mean that the Onion-Location value is just a
replacement for the protocol and domain parts of the URL, not a
replacement for the whole URL.

There may not be a 1:1 mapping in the URL space between the two URL
domains. At the very least, I would add a trailing slash (/) to the
example. The Healthy Onions developer seems to expect the string to end
with ".onion".

My personal website is a static site (mostly). In my implementation, I
took a list of all possible HTML URLs (excluding images, stylesheets,
etc.) and generated a list of corresponding onion locations.

I figured that being a blog, people often link to individual pages
instead of just to my homepage (which is probably the least useful page
on the site). Having the Onion-Location header on every page someone
could land on gives the best chance that they will discover the onion
service.

But then I realised that some of the locations I had generated
Onion-Locations for would also be serving Location headers as they were
old URLs. What should a browser do in this case? What should an
implementer do? In my implementation, I've thrown in the Onion-Location
headers regardless of whether or not a Location header is also present
because it was easier.

It could be preferable that the redirection is followed after switching
to the Onion service (i.e. Location header is ignored until user
responds to the Onion-Location header prompt), but this would mean the
page wouldn't have loaded before you get the prompt to go to the Onion
service, which may be confusing for users. Alternatively, if the page
has a Location header then the Onion-Location header should be ignored.

Thanks,
Iain.
Tom Ritter
2018-07-13 15:24:42 UTC
Permalink
Post by Iain Learmonth
Hi,
I've had a go at implementing this for my personal blog. Here are some
Good feedback!
Post by Iain Learmonth
My personal website is a static site (mostly). In my implementation, I
took a list of all possible HTML URLs (excluding images, stylesheets,
etc.) and generated a list of corresponding onion locations.
I figured that being a blog, people often link to individual pages
instead of just to my homepage (which is probably the least useful page
on the site). Having the Onion-Location header on every page someone
could land on gives the best chance that they will discover the onion
service.
Ah, that makes sense. You want /foo.html to serve an Onion-Location
that goes to /foo.html

But you're saying you did this manually for each file? I guess I
hadn't thought about how I would implement this (for Apache)... http
-> https redirection is done with mod_write, typically something like

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{SERVER_NAME}/$1 [R,L]

I don't mess with Apache/mod_rewrite much, but surely there's a way to
write out the Onion-Location header with the supplied path/querystring
automatically?
Post by Iain Learmonth
But then I realised that some of the locations I had generated
Onion-Locations for would also be serving Location headers as they were
old URLs. What should a browser do in this case? What should an
implementer do? In my implementation, I've thrown in the Onion-Location
headers regardless of whether or not a Location header is also present
because it was easier.
I think that is fine but....
Post by Iain Learmonth
It could be preferable that the redirection is followed after switching
to the Onion service (i.e. Location header is ignored until user
responds to the Onion-Location header prompt), but this would mean the
page wouldn't have loaded before you get the prompt to go to the Onion
service, which may be confusing for users. Alternatively, if the page
has a Location header then the Onion-Location header should be ignored.
I agree that if a Location header is present, the browser should
follow it immediately. If the subsequent location has an
Onion-Location header (and no Location header) then the browser should
prompt.

Location is a non-prompt, non-negotiable redirect.
Onion-Location is a prompted, user-chosen redirect.

The only question in my mind is if the user has opted in to always
following Onion-Location redirects, then the question is: which header
do you follow? And I would suggest Onion-Location although I don't
have a strong argument for that choice besides "It's our feature, we
should give it precedence."

-tom
Iain Learmonth
2018-07-13 19:23:41 UTC
Permalink
Hi,
Post by Tom Ritter
Ah, that makes sense. You want /foo.html to serve an Onion-Location
that goes to /foo.html
Exactly! But I might also want that /foo/bar.html goes to /bar.html on
the onion service while /baz/bar.html goes to /bar.html on another onion
service. Otherwise I don't think we can claim that the Onion-Location
header is similar to the Location header.
Post by Tom Ritter
But you're saying you did this manually for each file? I guess I
hadn't thought about how I would implement this (for Apache)... http
-> https redirection is done with mod_write, typically something like
My personal website is currently hosted by Netlify. They allow you to
provide a file that is used to send custom headers on a per-URL basis.

https://www.netlify.com/docs/headers-and-basic-auth/

I've attached the script I'm using for this. It's a manual step in that
I have to run the script. I could probably automate it if I learnt a
little more Hugo.
Post by Tom Ritter
I don't mess with Apache/mod_rewrite much, but surely there's a way to
write out the Onion-Location header with the supplied path/querystring
automatically?
I would imagine there are ways to configure this, but I don't know what
they are.
Post by Tom Ritter
I agree that if a Location header is present, the browser should
follow it immediately. If the subsequent location has an
Onion-Location header (and no Location header) then the browser should
prompt.
This sounds reasonable.
Post by Tom Ritter
Location is a non-prompt, non-negotiable redirect.
Onion-Location is a prompted, user-chosen redirect.
The only question in my mind is if the user has opted in to always
following Onion-Location redirects, then the question is: which header
do you follow? And I would suggest Onion-Location although I don't
have a strong argument for that choice besides "It's our feature, we
should give it precedence."
I think in this case, I would prefer to follow the Onion-Location header
first, as the user has chosen to make the usability trade-off for
security by enabling the automatic redirects.

Would it be worthwhile for me to write some text to this effect as a
patch for the proposal document?

Thanks,
Iain.
Georg Koppen
2018-09-21 10:44:00 UTC
Permalink
Post by George Kadianakis
[ text/plain ]
Post by George Kadianakis
As discussed in this mailing list and in IRC, I'm posting a subsequent
- Uses a new custom HTTP header, instead of Alt-Svc or Location.
- Does not do auto-redirect; it instead suggests the onion based on
antonella's mockup: https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
I don't see that or any particular idea of informing the user in the
proposal itself, though. I think more about those browser side plans
should be specified in it (probably in section 2). Right now you are
quite specific about the redirection part and its pro and cons but
rather vague on the actual UX improvements (having the header is just
half of what you need).
Hello,
pushed another commit to the onion-location branch in my repo for
https://gitweb.torproject.org/user/asn/torspec.git/commit/?h=onion-location&id=14fc750e3afcd759f4235ab955535a07eed24286
FYI: the proposal is now the first Tor Browser proposal:
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt

Georg
Rusty Bird
2018-09-21 12:59:31 UTC
Permalink
Post by Georg Koppen
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
Sounds great. One nit:

| Website operators should be aware that tools like tordnsel have
| false positive potential (they might treat Tor users as non-Tor users)

-> "false negative"

Rusty
Georg Koppen
2018-10-12 11:06:00 UTC
Permalink
Post by Rusty Bird
Post by Georg Koppen
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
| Website operators should be aware that tools like tordnsel have
| false positive potential (they might treat Tor users as non-Tor users)
-> "false negative"
Thanks, fixed (with commit 1582a35eb10c20c24bcfd008edea75d2803bbe0e).

Georg
Tom Ritter
2018-09-21 15:46:59 UTC
Permalink
Post by George Kadianakis
with the exact same
restrictions and semantics as the Location HTTP header
Maybe that should be 'syntax'? Semantics would mean that the header
behaves the same way right? But it doesn't. Location is a prompt-less
redirect, O-L is a prompted redirect. Additionally, O-L has an
additional restriction that the URI specified must be .onion?
Post by George Kadianakis
websites with lots of client traffic are encouraged
Why do we need to encourage them? Aren't they sufficiently motivated
themselves? I would go so far as to suggest they do _not_ do that,
because there is no fully reliable detection mechanism. But if they
want to, we 'can provide suggestions for them'?

And perhaps one suggestion is to detect User-Agent and only serve it
to one of the five user-agents that support Tor? (Since we discourage
anything else?) (TB, TBA, Brave, Orfox, OnionBrowser)

-tom
nusenu
2018-09-22 19:55:00 UTC
Permalink
(changed the subject to make clear that this is NOT about Alt-Svc anymore)

I assume this is limited to onions for sites that do not aim for server side location anonymity.
Post by Georg Koppen
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
in the light of the fact that this proposal has been started before
Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0])
I'm wondering how you think about it compared to what benefits Alt-Svc provides
over what Onion-Location provides?

Are you unsatisfied with what RFC 7838 - HTTP Alternative Services
provides or is "onion address is displayed in URL bar" one of your goals/requirements of this proposal?

Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3]
I find it addresses some rather important issues that 'Onion-Location' does not:

- users get the transport security benefits of .onions without Tor Browser displaying
hard/impossible to remember/recognize randomly looking strings.

Long randomly looking strings in the domain part of the URL that would probably
confuse many users and make it harder to answer the question "Am I still on the page I want to be?"
(I consider it a major UX improvement that you can display the non
.onion domain name while the traffic actually goes to the .onion)


- users will use onions transparently
without asking them questions they probably don't understand or don't want
to be bothered with everytime they visit a website [1]
I believe asking fewer questions, safe defaults and configuration options for advanced users
are some reasonable goals.

- it solves the ".onions can't get DV certs (yet)" issue






[0] https://blog.cloudflare.com/cloudflare-onion-service/
[1] https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
[2] https://trac.torproject.org/projects/tor/ticket/27590
[3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
d***@gmail.com
2018-09-26 06:50:43 UTC
Permalink
Before moving on from Alt-Svc, one idea that I thought would be great is
adding a new ALPN protocol ID [1] for HTTP/2 over onions, similar to "h2"
for HTTP/2 over TLS. Alec's post [2] reminded me of this and I'm sure
someone has considered this before, but if not now's a good time.

First, let's all agree that all non-onion websites have to use https,
otherwise none of this matters.

*Here's the gist of it:*

Let's consider the case of "h2" ALPN for HTTP/2 over TLS:
1. browser requests "https://foo.com", receives 'alt-svc:
h2="bar.onion:443"'
3. browser connects to bar.onion:443 port (this fails if tor socks isn't
set up)
4. the host must pass authentication [3], which for "h2" means giving a
valid certificate for "foo.com"
5. if authentication succeeds, browser displays "foo.com" but connects
using "bar.onion" and shows "bar.onion" in the circuit display.

This scenario is great for common websites because the cookie space is
always "foo.com", so the onion address can be transitory. In particular,
even if the website doesn't own the private key to the onion service,
authentication depends on TLS certificate for "foo.com", which the website
owns.


Now, the idea is to add "h2o" ALPN for HTTP/2 over TCP via an onion service:
1. browser requests"https://foo.com", receives 'alt-svc: *h2o*
="bar.onion:80'
3. normal browsers would ignore this, but Tor Browser connects to
bar.onion:80
4. the host *must still pass an authentication* step for "h2o" that Tor
Browser can invent
5. if authentication succeeds, *Tor Browser redirects to "bar.onion"*,
optionally noting "foo.com" in the circuit display.

For the "h2o" authentication step, TBB could:
1. Use a HTTPS Everywhere type extension
2. Require UI announcement + confirmation

This scenario is great for websites that want to separate cookie spaces "
foo.com" and "bar.onion" (you probably don't want a whistle-blower logged
in to your onion service suddenly send cookies over an exit node) or don't
want https+onion. Also, this is pretty much compatible with the Alt-Svc
specifications, so it doesn't require adding a new header.

Note that in this case the onion address is no longer transitory, so it's
important that the website should own the private key. This is critical
because unlike IP addresses, domain names, or even HTTPS certificates, the
private key to onion addresses doesn't expire (until offline/delegate keys
are implemented).

Thoughts?

[1]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
[2]
https://medium.com/@alecmuffett/onion-synopsis-for-susan-hennesey-b28a92f0e974
[3] https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1
Post by nusenu
(changed the subject to make clear that this is NOT about Alt-Svc anymore)
I assume this is limited to onions for sites that do not aim for server
side location anonymity.
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
in the light of the fact that this proposal has been started before
Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0])
I'm wondering how you think about it compared to what benefits Alt-Svc provides
over what Onion-Location provides?
Are you unsatisfied with what RFC 7838 - HTTP Alternative Services
provides or is "onion address is displayed in URL bar" one of your
goals/requirements of this proposal?
Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3]
- users get the transport security benefits of .onions without Tor Browser displaying
hard/impossible to remember/recognize randomly looking strings.
Long randomly looking strings in the domain part of the URL that would probably
confuse many users and make it harder to answer the question "Am I still
on the page I want to be?"
(I consider it a major UX improvement that you can display the non
.onion domain name while the traffic actually goes to the .onion)
- users will use onions transparently
without asking them questions they probably don't understand or don't want
to be bothered with everytime they visit a website [1]
I believe asking fewer questions, safe defaults and configuration options
for advanced users
are some reasonable goals.
- it solves the ".onions can't get DV certs (yet)" issue
[0] https://blog.cloudflare.com/cloudflare-onion-service/
[1]
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
[2] https://trac.torproject.org/projects/tor/ticket/27590
[3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2
--
https://twitter.com/nusenu_
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
mahrud <algorithms.jux-foundation.org/~mahrud/blog>
d***@gmail.com
2018-09-26 06:54:02 UTC
Permalink
Post by d***@gmail.com
Before moving on from Alt-Svc, one idea that I thought would be great is
adding a new ALPN protocol ID [1] for HTTP/2 over onions, similar to "h2"
for HTTP/2 over TLS. Alec's post [2] reminded me of this and I'm sure
someone has considered this before, but if not now's a good time.
First, let's all agree that all non-onion websites have to use https,
otherwise none of this matters.
*Here's the gist of it:*
h2="bar.onion:443"'
3. browser connects to bar.onion:443 port (this fails if tor socks isn't
set up)
4. the host must pass authentication [3], which for "h2" means giving a
valid certificate for "foo.com"
5. if authentication succeeds, browser displays "foo.com" but connects
using "bar.onion" and shows "bar.onion" in the circuit display.
This scenario is great for common websites because the cookie space is
always "foo.com", so the onion address can be transitory. In particular,
even if the website doesn't own the private key to the onion service,
authentication depends on TLS certificate for "foo.com", which the
website owns.
1. browser requests"https://foo.com", receives 'alt-svc: *h2o*
="bar.onion:80'
3. normal browsers would ignore this, but Tor Browser connects to
bar.onion:80
4. the host *must still pass an authentication* step for "h2o" that Tor
Browser can invent
5. if authentication succeeds, *Tor Browser redirects to "bar.onion"*,
optionally noting "foo.com" in the circuit display.
1. Use a HTTPS Everywhere type extension
2. Require UI announcement + confirmation
This scenario is great for websites that want to separate cookie spaces "
foo.com" and "bar.onion" (you probably don't want a whistle-blower logged
in to your onion service suddenly send cookies over an exit node) or don't
want https+onion. Also, this is pretty much compatible with the Alt-Svc
specifications, so it doesn't require adding a new header.
Note that in this case the onion address is no longer transitory, so it's
important that the website should own the private key. This is critical
because unlike IP addresses, domain names, or even HTTPS certificates, the
private key to onion addresses doesn't expire (until offline/delegate keys
are implemented).
Thoughts?
[1]
https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#tls-extensiontype-values-1
[2]
[3] https://tools.ietf.org/html/draft-ietf-httpbis-alt-svc-12#section-2.1
Post by nusenu
(changed the subject to make clear that this is NOT about Alt-Svc anymore)
I assume this is limited to onions for sites that do not aim for server
side location anonymity.
https://gitweb.torproject.org/tor-browser-spec.git/tree/proposals/100-onion-location-header.txt
in the light of the fact that this proposal has been started before
Tor Browser 8 with Alt-Svc support for .onions was a thing (and CF jumping on it [0])
I'm wondering how you think about it compared to what benefits Alt-Svc provides
over what Onion-Location provides?
Are you unsatisfied with what RFC 7838 - HTTP Alternative Services
provides or is "onion address is displayed in URL bar" one of your
goals/requirements of this proposal?
Although Alt-Svc does not work reliably _yet_ and the UI part is missing [3]
- users get the transport security benefits of .onions without Tor Browser displaying
hard/impossible to remember/recognize randomly looking strings.
Long randomly looking strings in the domain part of the URL that would probably
confuse many users and make it harder to answer the question "Am I still
on the page I want to be?"
(I consider it a major UX improvement that you can display the non
.onion domain name while the traffic actually goes to the .onion)
- users will use onions transparently
without asking them questions they probably don't understand or don't want
to be bothered with everytime they visit a website [1]
I believe asking fewer questions, safe defaults and configuration options
for advanced users
are some reasonable goals.
- it solves the ".onions can't get DV certs (yet)" issue
[0] https://blog.cloudflare.com/cloudflare-onion-service/
[1]
https://trac.torproject.org/projects/tor/attachment/ticket/21952/21952.png
[2] https://trac.torproject.org/projects/tor/ticket/27590
[3] https://trac.torproject.org/projects/tor/ticket/27590#comment:2
--
https://twitter.com/nusenu_
_______________________________________________
tor-dev mailing list
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
--
mahrud <algorithms.jux-foundation.org/~mahrud/blog>
--
mahrud <algorithms.jux-foundation.org/~mahrud/blog>
Tom Ritter
2018-10-23 16:24:56 UTC
Permalink
...
I want to compare your proposal with the simple situation of "If the
server gets a connection from a Tor exit node, return Location:
blah.onion." (This would also separate the cookie space)

If I understand your proposal correctly, the differences are:

1) Because the client offers h2o in ALPN, the server knows (at initial
TLS connection time) the client supports .onion transport. (We also
leak this out onto the network in plaintext; but since it comes from
an exit node it's not too concerning?)

2) The server offers h2o as an Alt-Svc protocol, so any client not
supporting onions will ignore it gracefully. There is no concern that
the server could send a Location: blah.onion header to a client not
supporting onions; or omit it from a client supporting onions.

3) Tor Browser can implement additional authentication checks for the
transfer from blah.com -> blah.onion

I'm not clear if the connection to blah.onion involves HTTPS or HTTP;
but I suppose both are possible.

Because the response from the server comes from


So I like to try and keep the intent of headers as close as possible.
Alt-Svc is used to redirect routing without visible changes and
without user prompting. That's why I'm opposed to Alt-Svc:
h2/blah.onion prompting the user, and opposed to the Location: header
prompting the user but am perfectly supportive of a new Onion-Location
header prompting the user. Creating h2o for Alt-Svc and implementing
it in a way that redirects the user violates the intent of Alt-Svc.

Additionally, ALPN is designed for negotiating an Application Layer
Protocol - what you speak inside TLS. h1 and h2 are different
protocols, so one uses ALPN to negotiate h2 in the TLS connection, and
the first byte of the application layer protocol is HTTP2. In your
proposal; you negotiate a different protocol, but still speak h2.
Actually it's not clear if one should speak HTTP or HTTP2 to the
server! (We could require http2 but that seems like a bad idea.)

The response from the server still comes in the Alt-Svc header; so
there's no connection latency to be avoided.

I like the goal of giving server operators the ability to separate
cookie spaces. But I think that's accomplished by both a prompted
Onion-Location redirect or a non-prompted Location redirect.

I like the goal of having no ambiguity or confusion about what a
browser that does/doesn't support onion should do with an onion
address or possibility of not serving an onion address to someone who
should get. Onion-Location solves this for prompted redirects.
Location does not solve this for promptless redirects. (We could add a
'force' parameter to Onion-Location to bypass the prompt. I think this
is a good idea and would suggest we add it to the proposal.)

I think the idea of allowing Tor Browser to require and perform
additional security checks for the transfer from http(s) -> onion. But
I don't see why they couldn't be added/performed as part of the
Onion-Location transfer.

I like the idea of using ALPN for something; but I don't think this is
the right problem to use it for. Because it's used for Application
Layer Protocol selection, it is the perfect choice to use to negotiate
a Tor connection or a Pluggable Transport connection to a server
supporting both a website and Tor. (Imagine if that were deployed on
something like Github!) But it's _in plaintext_. So any connection
offering such an ALPN could be blocked. I'm still disappointed the WG
chose ALPN instead of NPN. With this plaintext limitation, I don't
know what we could use ALPN for. Maybe we could use it inside normal
Tor connections to negotiate a new Tor protocol that didn't nicely fit
into the existing tor protocol version negotiation.

-tom
Alec Muffett
2018-10-23 17:15:05 UTC
Permalink
1) the best and proper way to redirect from site A to site B is to use
"Location:" and/or an appropriate 3xx code. It already works.

2) having an "h2o" ALPN for Alt-Svc would literally make things worse,
retard adoption, confuse implementations, break almost all of my future
plans for onionification of corporations, and generally make life a pain.
It's hard enough getting people to implement functionality in early stages
when there are merely bugs, let alone forcing them to jump through hoops to
implement special, redundant magical headers that literally do not serve
any additional functional value above the extant, open, standard, supported
ones.

3) if sites wish to follow Privacy International's example and redirect
from a DNS TLD to ".onion" then that is something they should implement at
layer 7, by dint of identifying whether the user has arrived over Tor. (See
below)

4) if sites want to advertise the existence of an alternate onion site by
leveraging some form of tor-specific browser pop down, then sure, knock
yourself out with a magical header but nobody in their right mind is going
to deploy it in the Enterprise. It would be a massive waste of human / tech
bandwidth and hassle. It would be far easier and cheaper instead to react
having first identified whether the user has arrived over Tor.

5) onion networking already works for h2 ALPN under alt-svc; please do not
mess this up by fragmenting it / imagining that it needs to take-on a
special syntax to reflect it's "onion nature". I get what you are saying,
it's very clever, but please: no. There is a vast amount of potential for
organisations to "turbocharge" their Tor user-experience by simply offering
an "h2" onion address amongst Alt-Svc when a user connects to them via an
exit node. Everything is already sufficiently disambiguated by the ".onion"
suffix. We're good.

6) a moment's consideration will illuminate that the underlying problem
here is the increasing fallacy which Tor continues to suffer, that sites
should/do not know that a user is arriving over Tor. That half of the
websites in the world should be kept in ignorance that a user is arriving
via Tor, while the other half - the popular sites by volume - actively want
to know that the user is arriving over Tor in order to optimise the user's
experience.

In short we have conflicting desires: some tor users want to pretend that
they are just some schmoe (sp?) running Firefox on Windows on a "random
machine somewhere on the internet" - e.g. a fat exit node run by Mozilla


But any website that takes an interest (e.g. tracks Cloudflare's "xx-tor"
country geolocation, or whatever it is called) - regarding the reputation
of the source IP address will KNOW that the user is coming from Tor.

We live in a weird world where the Tor community still believes that
systems administrators don't have trivial access to IP reputation databases.

The world has changed since Tor was first invented; perhaps it's time that
we stopped trying to hide the fact that we are using Tor? Certainly we
should attempt to retain the uniformity across all tor users - everybody
using Firefox on Windows and so forth - but the fact that/when traffic
arrives from Tor is virtually unhideable.

Consciously sacrificing that myth would make uplift to onion networking so
much simpler.

- a
Tom Ritter
2018-10-23 22:47:11 UTC
Permalink
Post by Alec Muffett
The world has changed since Tor was first invented; perhaps it's time that
we stopped trying to hide the fact that we are using Tor? Certainly we
should attempt to retain the uniformity across all tor users - everybody
using Firefox on Windows and so forth - but the fact that/when traffic
arrives from Tor is virtually unhideable.
Consciously sacrificing that myth would make uplift to onion networking so
much simpler.
I agree.

In particular because I want to avoid false positives and false negatives
in the reputation system.

But by what mechanism do we expose this information? I can't think of one
that doesn't have significant drawbacks. And what do we say/what do we
mean? (I am onion capable?)
nusenu
2018-10-25 21:57:00 UTC
Permalink
(just pasting the references from twitter threads, I'm not
sure if there is a nice way to view the entire thread and all subthreads without missing any)
Post by Alec Muffett
perhaps it's time that
we stopped trying to hide the fact that we are using Tor?
https://twitter.com/sjmurdoch/status/1054797781343330307
https://twitter.com/arthuredelstein/status/1054835301028253696
Post by Alec Muffett
the fact that/when traffic
arrives from Tor is virtually unhideable.
related
https://lists.torproject.org/pipermail/metrics-team/2018-September/000914.html
--
https://twitter.com/nusenu_
https://mastodon.social/@nusenu
Iain Learmonth
2018-10-26 10:38:58 UTC
Permalink
Hi,
Post by Alec Muffett
But any website that takes an interest (e.g. tracks Cloudflare's
"xx-tor" country geolocation, or whatever it is called) - regarding the
reputation of the source IP address will KNOW that the user is coming
from Tor. 
We live in a weird world where the Tor community still believes that
systems administrators don't have trivial access to IP reputation databases.
IP reputation databases do not reflect the current state of the Tor
network exactly. They may be pretty close, even 99%, but they're not
exact. You will get false positives, and a lot of false negatives too.

Improving exit detection is on the list of tasks for Tor Metrics but it
is not our top priority.
Post by Alec Muffett
3) if sites wish to follow Privacy International's example and
redirect from a DNS TLD to ".onion" then that is something they should
implement at layer 7, by dint of identifying whether the user has
arrived over Tor.

Given that false positives are possible, doing this conditionally is
going to give some people a terrible user experience by redirecting them
to an onion they cannot possibly reach in their browser.

This is why I like the Onion-Location header. You don't have to have
this conditional. You don't need to have any infrastructure to provide
lookups from databases (which ideally would need to be refreshed
constantly). You just always serve the header. This also gives you the
opportunity to advertise that a service is available via Onion service
to all users, some of which might have a browser add-on that lets them
know about these things.

Thanks,
Iain.

Loading...