[tor-access] Specification for bypassing CAPTCHAs using blinded tokens

Mike Perry mikeperry at torproject.org
Mon Oct 17 23:08:49 UTC 2016


Alex Davidson:
> Hi everyone,
> 
> I've been interning at Cloudflare for the past 3 months and have been
> working on developing an implementation of the blinded tokens spec that
> George and Filippo developed a while back.
> 
> We've updated aspects of the original spec, the newest spec can now be
> viewed here: https://github.com/cloudflare/challenge-bypass-specification.
> We're happy to hear comments from any of you on the design and on the
> capacity of the solution for preserving anonymity.

I have a quick question about this comment in the spec in Section 8.1:
https://github.com/cloudflare/challenge-bypass-specification/blob/master/captcha-bypass-formal-spec.txt#L375

"Since Cloudflare controls the origins, it could currently correlate
user sessions across multiple circuits using these cookies. This is a
gap in the Tor Browser threat model- the design explicitly ignores
linking within a session by malicious first parties, but Cloudflare has
effectively first-party control over a large proportion of the web."

The Tor Browser threat model actually does cover this. We call this
"Cross-Origin Identifier Unlinkability". We isolate all browser state to
the first party to prevent exactly this type of tracking.

This *should*[1] mean that even though CloudFlare controls a lot of
first parties, it still can't track users from first party to first
party simply though cookies/supercookies, etc. So even if CloudFlare
controls both abc.com and xyz.com, the cookies, DOM Storage, and even
TLS state set on abc.com are not visible on xyz.com and vice versa (even
if both abc.com and xyz.com source eachother as third parties on their
respective sites).

If, through your research into this work, or elsewhere in CloudFlare,
you folks have actually found ways around this tracking protection, we
would like to know about them. Any details would be appreciated.


[1]. As far as I know, the only major issue we are aware of is that we
currently don't differentiate between fully automated first party
redirect loops and user-initiated federated login clicks. We've been
thinking about building some mechanism for differentiating these, so we
could still support federated login but prevent automated redirect
tracking, but first party redirect loops like this are pretty
noticeable, and so far we have not seen this abused. If you think
otherwise, or if there are other ways to circumvent our tracking
protection if first parties cooperate, that would be useful to know.


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-access/attachments/20161017/7ba5bc1f/attachment.sig>


More information about the tor-access mailing list