[tor-bugs] #32256 [- Select a component]: TorBrowser should advertise Onion Networking capability in the User-Agent: string

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Oct 24 10:32:27 UTC 2019


#32256: TorBrowser should advertise Onion Networking capability in the User-Agent:
string
----------------------------------+------------------------
 Reporter:  alecmuffett           |          Owner:  (none)
     Type:  enhancement           |         Status:  new
 Priority:  Medium                |      Milestone:
Component:  - Select a component  |        Version:
 Severity:  Normal                |     Resolution:
 Keywords:                        |  Actual Points:
Parent ID:                        |         Points:
 Reviewer:                        |        Sponsor:
----------------------------------+------------------------
Description changed by alecmuffett:

Old description:

> For many years, it's been expected that people who use Tor to surf the
> web, need to hide the fact that they are using Tor, and that the best way
> to achieve that is to attempt to mimic some other browser - typically
> Windows-Firefox or similar.
>
> There is no argument that other protections such as protecting screen
> sizes and so forth, continue to be useful in protecting the user against
> fingerprinting and tracking, so those and other protections should
> certainly continue.
>
> However, there can be no reasonable argument against the observation
> that:
>
> -  the world treats any inbound TCP connection from a Tor exit node as
> "traffic from Tor"
>
> - there exist any number of "IP reputation" systems which track (with
> varying amounts of lag) the state of the Tor exit node cloud, and
> essentially assign Tor a "geography" and offer the user the opportunity
> to "block" it, etc
>
> - that there exist some number of sites which would like to do something
> "nice" for Tor users (there are people who would like to do something
> "nasty", too, but those people are already served by upstream geoblock
> providers) and those sites are typically hampered by having no concept of
> "How many of our users are legitimate people coming from a Tor Browser?"
>
> So: people who use Tor to access a website are:
>
> 1/ immediately "outed" as coming from Tor, by virtue of their apparent IP
> address
>
> 2/ treated as a faceless group, worthy of (usually: trivial) blocking, by
> flicking a "Block Bad Sites" IP-reputation switch
>
> 3/ hard to identify at "Layer-7" (ie: web logs) as being legitimate users
>
> ...and...
>
> 4/ any Trolls amongst the Tor userbase who harass <website community> are
> investigated, determined as "being from Planet Tor" and thereby drag down
> the reputation of Tor even further.
>
> Two personal observations are useful here:
>
> a) When I was building the Facebook Onion, we had to run an experiment
> which was essentially "Are the people who access Facebook over Tor,
> generally bad people?" - because common sense suggested that we check
> this.  We checked a sample of users who accessed Facebook over Tor, and
> found that overwhelmingly (> %95) they were just normal users doing
> normal things.  This was a realisation, and combined with the scale of
> Tor usage, led to the creation of the Facebook onion.
>
> b) Conversations with [people at Cloudflare] who noted to me that
> TorBrowser's attempts to "hide" meant that in site-protection "flows"
> (think: Captchas) it was hard to economically (think: experience latency
> from a geocheck hit) identify TorBrowser users so as to give them special
> consideration and care.
>
> Therefore, I propose that TorBrowser be amended to include "OnionCapable"
> - or "TorCapable" or some other well-advertised, similar string - in the
> "User-Agent" header of the browser.
>
> == Why the User-Agent?
>
> Because if a special, magic header were created, it would probably be
> dropped en-route upstream.
>
> Also: site owners already know how to act on User-Agent strings, whereas
> new headers would be considered "deep magic".
>
> There is the possibility to go to a commercial CDN and ask them to serve
> certain content or return certain headers ("Alt-Svc:
> foofoofoofoofoof.onion" perhaps?) on the basis of "User-Agent", but
> asking them to detect and act upon the presence of "X-Tor-Browser-
> Special-Header:1" would be onerous and unlikely to succeed.
>
> == But what about Logs?
>
> Let's think about that threat model:
>
> - We want more people to use Tor because it's a better network.
>
> - We want sites to know that their users are using Tor
>
> - Tor usage can be inferred anyway, from IP addresses and time cross-
> checked against relay logs
>
> So what's the concrete problem, here? Perhaps that some Stasi will in
> some case subpoena the logs of a service provider and then use that to
> prove that [person] was using Tor at the time? That's a pretty small risk
> compared to concretely enabling better Tor for everyone.
>
> == What about #21952 ?
>
> That's some interesting client-side work, and I am sure that it would
> benefit from telling the server "I can do Tor, please be nice to me", but
> otherwise it's essentially disjoint.
>
> == But many many site owners will detect this new header and block Tor
> access!
>
> If they are inclined they they already do, and it's probably better to
> enable them get it out of the way more easily, so that their behaviour
> and attitudes can be called-out.
>
> If a site is so trivially tricked that their "OnionCapable" detection is
> their only protection, then this also screams for a TorBrowserExtension
> which tests whether that header is being detected and causing blocking,
> which will help enumerate hostile sites for public awareness.
>
> = tl;dr
>
> Sites, if they care, can already determine whether someone is accessing
> them from Tor.
>
> If such determination were made easier, other sites could be nicer to Tor
> users
>
> Tor would become even more normal.
>
> It's time for TorBrowser to come out of the closet.

New description:

 For many years, it's been expected that people who use Tor to surf the
 web, need to hide the fact that they are using Tor, and that the best way
 to achieve that is to attempt to mimic some other browser - typically
 Windows-Firefox or similar.

 There is no argument that other protections such as protecting screen
 sizes and so forth, continue to be useful in protecting the user against
 fingerprinting and tracking, so those and other protections should
 certainly continue.

 However, there can be no reasonable argument against the observation that:

 -  the world treats any inbound TCP connection from a Tor exit node as
 "traffic from Tor"

 - there exist any number of "IP reputation" systems which track (with
 varying amounts of lag) the state of the Tor exit node cloud, and
 essentially assign Tor a "geography" and offer the user the opportunity to
 "block" it, etc

 - that there exist some number of sites which would like to do something
 "nice" for Tor users (there are people who would like to do something
 "nasty", too, but those people are already served by upstream geoblock
 providers) and those sites are typically hampered by having no concept of
 "How many of our users are legitimate people coming from a Tor Browser?"

 So: people who use Tor to access a website are:

 1/ immediately "outed" as coming from Tor, by virtue of their apparent IP
 address

 2/ treated as a faceless group, worthy of (usually: trivial) blocking, by
 flicking a "Block Bad Sites" IP-reputation switch

 3/ hard to identify at "Layer-7" (ie: web logs) as being legitimate users

 ...and...

 4/ any Trolls amongst the Tor userbase who harass <website community> are
 investigated, determined as "being from Planet Tor" and thereby drag down
 the reputation of Tor even further.

 Two personal observations are useful here:

 a) When I was building the Facebook Onion, we had to run an experiment
 which was essentially "Are the people who access Facebook over Tor,
 generally bad people?" - because common sense suggested that we check
 this.  We checked a sample of users who accessed Facebook over Tor, and
 found that overwhelmingly (> %95) they were just normal users doing normal
 things.  This was a realisation, and combined with the scale of Tor usage,
 led to the creation of the Facebook onion.

 b) Conversations with [people at Cloudflare] who noted to me that
 TorBrowser's attempts to "hide" meant that in site-protection "flows"
 (think: Captchas) it was hard to economically (think: experience latency
 from a geocheck hit) identify TorBrowser users so as to give them special
 consideration and care.

 Therefore, I propose that TorBrowser be amended to include "OnionCapable"
 - or "TorCapable" or some other well-advertised, similar string - in the
 "User-Agent" header of the browser.

 == Why the User-Agent?

 Because if a special, magic header were created, it would probably be
 dropped en-route upstream.

 Also: site owners already know how to act on User-Agent strings, whereas
 new headers would be considered "deep magic".

 There is the possibility to go to a commercial CDN and ask them to serve
 certain content or return certain headers ("Alt-Svc:
 foofoofoofoofoof.onion" perhaps?) on the basis of "User-Agent", but asking
 them to detect and act upon the presence of "X-Tor-Browser-Special-
 Header:1" would be onerous and unlikely to succeed.

 == But what about Logs?

 Let's think about that threat model:

 - We want more people to use Tor because it's a better network.

 - We want sites to know that their users are using Tor

 - Tor usage can be inferred anyway, from IP addresses and time cross-
 checked against relay logs

 So what's the concrete problem, here? Perhaps that some Stasi will in some
 case subpoena the logs of a service provider and then use that to prove
 that [person] was using Tor at the time? That's a pretty small risk
 compared to concretely enabling better Tor for everyone.

 == What about #21952 ?

 That's some interesting client-side work, and I am sure that it would
 benefit from telling the server "I can do Tor, please be nice to me", but
 otherwise it's essentially disjoint.

 == But many many site owners will detect this new header and block Tor
 access!

 If they are inclined then they already do, and it's probably better to
 enable them get it out of the way more easily, so that their behaviour and
 attitudes can be called-out.

 If a site is so trivially tricked that their "OnionCapable" detection is
 their only protection, then this also screams for a TorBrowserExtension
 which tests whether that header is being detected and causing blocking,
 which will help enumerate hostile sites for public awareness.

 = tl;dr

 Sites, if they care, can already determine whether someone is accessing
 them from Tor.

 If such determination were made easier, other sites could be nicer to Tor
 users

 Tor would become even more normal.

 It's time for TorBrowser to come out of the closet.

--

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/32256#comment:1>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online


More information about the tor-bugs mailing list