[tbb-bugs] #18361 [Tor Browser]: Issues with corporate censorship and mass surveillance

[Tor Bug Tracker & Wiki]

#18361: Issues with corporate censorship and mass surveillance
------------------------------------------+--------------------------
 Reporter:  ioerror                       |          Owner:  tbb-team
     Type:  enhancement                   |         Status:  new
 Priority:  High                          |      Milestone:
Component:  Tor Browser                   |        Version:
 Severity:  Critical                      |     Resolution:
 Keywords:  security, privacy, anonymity  |  Actual Points:
Parent ID:                                |         Points:
  Sponsor:                                |
------------------------------------------+--------------------------

Comment (by massar):

 Another option that CloudFlare can attempt:

  - user goes to website https://hostedbyCDN.com
  - CDN decided "hmmmm, we need extra protection", lets ask for a captcha!
  - Redirect to https://CDNCaptcha.com/?url=https://hostedbyCDN.com
  - user solves captcha hosted on that site -> JWT based cookie gets set
 for CDNCaptcha.com that the user solved a captcha for domain
 CDNCaptcha.com and that it expires in say 4 hours.
  - user gets redirected to https://hostedbyCDN.com/CDNCaptcha=<JWT>
     That JWT signs that CDNCaptha.com proved that a captcha was signed and
 acceptable for use for hostedbyCDN.com

 ...
 .
  - user goes to another site: https://othersitebyCDN.com
  - user gets redirected to
 https://CDNCaptcha.com/?url=https://othersitebyCDN.com to solve captcha,
 cookie gets sent
  - CDNCaptcha.com notices "hey, a valid cookie"
  - user gets automatically (without solving any captcha) send back to
 original site: https://hostedbyCDN.com/CDNCaptcha=<JWT-that-it-is-okay>,
 which sets a cookie that the user is 'cool'.

 This way, captchas are all handled in one place and thus no need to keep
 on resolving captchas.

  - It does mean that the CDN must steal /CDNCaptacha/* url from every
 site, as otherwise there is no way to pass the cookies across sites
 (cookies don't do cross site boundaries fortunately)

 - It could attack anonimity if the same JWT is served globally and thus
 enable tracking based on that. Hence, it would be great if a different JWT
 is generated per site. Thus maybe encode the domainname in the JWT (this
 also ensures that the cookie was provided for that domain.

  - The CDNCaptcha.com can see all requests and domains that user is
 accessing. But that is the same thing that Google sees everything and can
 correlate requests (eg when logging in or by setting tracking cookies, or
 letting sites include www.google.com/ javascript etc etc) or just keeping
 a huge database.

 The usage of JWT means that there is no state on the side of the CDN.
 There is state (cookies) in the client, but there is no real way around
 it.
 As the JWTs are different,

 If we standardise the cookie name, we could let TBB do a verification that
 the cookie's JWT content are different for each site visited, thus making
 sure that (except for CDNCaptcha.com who could store everything) is
 issuing per-domain/host cookies.

 Another thing that TBB could do is warn that this special CDNCaptcha.com
 is used and if the user wants to solve a new captcha or re-use the
 previous approval.

 Note that the above requires Cookies to be enabled, but it does not
 require any form of javascript except for the CDNCaptcha.com site, thus
 allowing a user to decide "I want easier captchas that require javascript,
 lets allow it for this specific site" (Ublock Origin+++++ unfortunately
 not in TBB yet...).


 If we then add the Tor .onion access I mentioned in a previous comment,
 anonimity would be pretty well served ;)

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