Re: [tor-dev] Request for feedback/victims: cfc-0.0.2

[Yawning Angel]

On Sat, 2 Apr 2016 18:14:26 -0400
Ian Goldberg  wrote:

> On Sat, Apr 02, 2016 at 07:19:30PM +, Yawning Angel wrote:
> > It's not a request header set by the browser.  archive.is is acting
> > like a HTTP proxy and explicitly setting X-F-F.  
> 
> I wonder what would happen if the browser *also* set X-F-F...?

Unfortunately, it appears that archive.is tramples over X-F-F if it is
already set.  Maybe others will have better luck engaging with the
operator(s) of archive.is than I have.

Regards,

-- 
Yawning Angel


pgpHSqIn1dO_s.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc-0.0.2

[Yawning Angel]

On Fri, 01 Apr 2016 18:21:10 +0200
Jeff Burdges  wrote:

> Are there any more sites where CloudFalre appears on archive.is?
> 
> https://www.aei.org/publication/gen-michael-hayden-on-apple-the-fbi-and-data-encryption/
> ​https://archive.is/7u5P8
>
> It's some particularly harsh CloudFlare configuration perhaps? 

Without knowing how archive.is works, and how CloudFlare works, it's
hard to tell.

Since archive.is sets "X-Forwarded-For", it's not particularly hard to
figure out if a Tor user is the one requesting a snapshot.  I requested
a new snapshot and the captcha error page in the archive shows that
the IP of my exit, so part of the ClouldFlare infrastructure at least
peeks at the header.

I'll probably add support for other (user-configurable?) cached content
providers when I have time.  The archive.is person doesn't seem to want
to respond to e-mail, so asking them to optionally not set X-F-F, seems
like it'll go absolutely nowhere.

Regards,

-- 
Yawning Angel


pgpbdDFFzx9_I.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc-0.0.2

[Jeff Burdges]

I'm impressed with how much nicer the web gets with this. Thank you
Yawning!  :) 

On Sun, 2016-03-27 at 06:12 +, Yawning Angel wrote:

>* (QoL) Skip useless landing pages (github.com/twitter.com will be
>  auto-redirected to the "search" pages).

Ahh that's why that happened.  lol

>* (Privacy) Kill twitter's outbound link tracking (t.co URLs) by
>  rewriting the DOM to go to the actual URL when possible.  Since
>  DOM changes made from content scripts are isolated from page
>  scripts, this shouldn't substantially alter behavior.

Nice!

> TODO:
> 
>  * Try to figure out a way to mitigate the ability for archive.is to
>track you.  The IFRAME based approach might work here, needs more
>investigation.

Interesting point.

>  * Handle custom CloudFlare captcha pages (In general my philosophy is
>to minimize false positives, over avoiding false negatives).
>Looking at the regexes in dcf's post, disabling the title check may
>be all that's needed.

I've noticed some hiccups with medium on the auto mode, like say
https://medium.com/@octskyward/the-resolution-of-the-bitcoin-experiment-dabb30201f7
It sometimes works if you hit refresh though.

>  * Look into adding a "contact site owner" button as suggested by Jeff
>Burdges et al (Difficult?).

Just noticed this minimalist whois client in node.js : 
https://github.com/carlospaulino/node-whoisclient/blob/master/index.js 

>  * Support a user specified "always use archive.is for these sites"
>list.
> 
>  * UI improvements.

A task bar icon might find several uses:
- A "View this page through archive.is" button for when CFC misses a
CAPTCHA, or even if the CAPTCHA is not CloudFlare.
- A "contact site button" that worked even after passing to archive.is.
- A "Give me the CAPTCHA" button for those who configure CFC to
automatically load archive.is.  

I'm using another browser profile for this last point currently.  In
fact, it fit perfectly into my existing pattern of browser profiles.
Yet, browser profiles are not user-friendly, especially in TBB, so this
would benefit people who do not use profiles. 

Wonderful extension!
Jeff




signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc-0.0.2

[Jens Kubieziel]

* Yawning Angel schrieb am 2016-03-27 um 08:12 Uhr:
>* (QoL) Skip useless landing pages (github.com/twitter.com will be
>  auto-redirected to the "search" pages).

When you're logged into Twitter, https://twitter.com/ shows you your
stream of tweets. With the current version, a user can't see its own
stream anymore. Can you redirect to the search page only for
non-logged-in users?

-- 
Jens Kubieziel   http://www.kubieziel.de
21 ist nur die halbe Wahrheit


signature.asc
Description: Digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Request for feedback/victims: cfc-0.0.2

[Yawning Angel]

Hello,

Thanks for the feedback so far.

  [ PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL
STILL SHOULD NOT USE THIS. ]

New version with changes some that add functionality, some code of
quality stuff, hence a version bump to 0.0.2, especially since it'll
probably be a bit before I can focus on tackling the TODO items.

Source: https://git.schwanenlied.me/yawning/cfc
XPI: https://people.torproject.org/~yawning/volatile/cfc-20160327/

Major changes:

 * Properly deregister the HTTP event listeners on addon unload.

 * Toned down the snark when I rewrite the CloudFlare captcha page,
   since I wasn't very nice.

 * Additional quality of life/privacy improvements courtesy of Will
   Scott, both optional and enabled by default.

   * (QoL) Skip useless landing pages (github.com/twitter.com will be
 auto-redirected to the "search" pages).

   * (Privacy) Kill twitter's outbound link tracking (t.co URLs) by
 rewriting the DOM to go to the actual URL when possible.  Since
 DOM changes made from content scripts are isolated from page
 scripts, this shouldn't substantially alter behavior.

   * (Code quality) Use a pref listener to handle preference changes.

TODO:

 * Try to figure out a way to mitigate the ability for archive.is to
   track you.  The IFRAME based approach might work here, needs more
   investigation.

 * Handle custom CloudFlare captcha pages (In general my philosophy is
   to minimize false positives, over avoiding false negatives).
   Looking at the regexes in dcf's post, disabling the title check may
   be all that's needed.

 * Handle CloudFlare 503 pages.

 * Get samples of other common blanket CDN based Tor blocking/major
   sites that block Tor, and implement bypass methods similar to how
   CloudFlare is handled.

 * Look into adding a "contact site owner" button as suggested by Jeff
   Burdges et al (Difficult?).

 * Support a user specified "always use archive.is for these sites"
   list.

 * UI improvements.

 * More Quality of Life/Privacy improvements (Come for the Street
   Signs, stay for the user scripts).

   * I will eventually get annoyed enough at being linked to mobile
 wikipedia that I will rewrite URLs to strip out the ".m.".

 * Test this on Fennec.

 * Maybe throw this up on addons.mozilla.org.

Regards,

-- 
Yawning Angel


pgpKqMog0USwp.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[Jeff Burdges]

On Wed, 2016-03-23 at 14:09 -0400, Paul Syverson wrote:
> On Wed, Mar 23, 2016 at 12:33:15PM -0400, Adam Shostack wrote:
> > Random thought: rather than "unreachable from Tor", "unreachable when
> > using the internet safely."  This is really about people wanting
> > security, and these companies not wanting to grapple with what their
> > customers want.
> 
> Yes! Not random at all. When trying to succincly contrast current means
> to access and use registered-domain sites vs. onionsites I not infrequently
> slip into calling them the insecure web and the secure web respectively.

Yes, that sounds reasonable.  There would be a bunch of linguistic
decisions like that.  I suggested waiting until Kate finishes her
CloudFlare FAQ specifically because she would already be making many
relevant such decisions. 

I think the main technical question is : How hard is it to safely use
whois from JavaScript? 

Jeff



signature.asc
Description: This is a digitally signed message part
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[Arthur D. Edelstein]

On Wed, Mar 23, 2016 at 2:15 AM, Yawning Angel  wrote:

> My "proof of concept" tech demo is what I consider good enough for
> use by brave people that aren't me, so I have put up an XPI package
> at: https://people.torproject.org/~yawning/volatile/cfc-20160323/

Very cool!

>  * If archive.is is evil, they can track you across page fetches
>trivially, because this sort of use case is outside of Tor Browser's
>current threat model (Yes, CloudFlare/Google can also do the same
>thing currently, who do you trust more?).

Because CloudFlare presents its captcha page under the target site's
domain name, and the Google ReCAPTCHA iframe is embedded inside that,
Tor Browser is designed to prevent tracking across visits to different
CloudFlared sites. So in that sense the archive.is option allows more
tracking.

One possible solution could be for the extension to replace the HTML
content inside a desired content page (say,
https://imgur.com/some-page.html) with an iframe containing the
archive.is version. The iframe would then be embedded under the
desired first-party domain (e.g., imgur.com instead of archive.is) so
that the page requests and caching are isolated to imgur.com.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[Paul Syverson]

On Wed, Mar 23, 2016 at 12:33:15PM -0400, Adam Shostack wrote:
> Nice!
> 
> Random thought: rather than "unreachable from Tor", "unreachable when
> using the internet safely."  This is really about people wanting
> security, and these companies not wanting to grapple with what their
> customers want.

Yes! Not random at all. When trying to succincly contrast current means
to access and use registered-domain sites vs. onionsites I not infrequently
slip into calling them the insecure web and the secure web respectively.

aloha,
Paul
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[Griffin Boyce]

Yawning Angel wrote:

Inspired by https://trac.torproject.org/projects/tor/ticket/18361
I've been working on way to improve the situation.


  Neat. In the thread someone mentions that it's possible to derive the 
answer for the old-style street number captchas using tesseract [1]. 
Interestingly, there is a version of tesseract in javascript [2]. This 
is probably not especially useful for the current "select all boxes that 
contain one pixel of street sign" Recaptcha system, but if there were a 
way to trigger the old behavior, these techniques could be used 
together.


~Griffin

[1] https://trac.torproject.org/projects/tor/ticket/18361#comment:173
[2] http://tesseract.projectnaptha.com/

--
“Not having a clear goal leads to death by a thousand compromises.”
~ Mark Pincus
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[David Fifield]

During the OONI survey to find instances of server-side Tor blocking, we
found a few variations on CloudFlare captcha pages. They don't all say
"Attention Required!". Apparently there is an option to customize the
page, but few sites make use of it. Here are the regexes we used
(excerpted from https://www.bamsoftware.com/git/ooni-tor-blocks.git):
if status == 403:
if server == "cloudflare-nginx" and re.search("Attention 
Required! \\| CloudFlare|One more step to access", body):
return True, "403-CLOUDFLARE"
if server == "cloudflare-nginx" and re.search("|", body):
# A customized captcha page.
return True, "403-CLOUDFLARE"
if server == "cloudflare-nginx" and re.search("Access denied \\| 
[^ ]* used CloudFlare to restrict access", body):
# With this one you don't get a captcha. May be controlled by the
# site operator.
return True, "403-CLOUDFLARE"
if status == 503:
if re.search("", body):
return True, "503-CLOUDFLARE"
I now think the 'server == "cloudflare-nginx"' tests are unnecessary.
The last two patterns above don't even give you a captcha to solve, just
deny access. You might want to limit your detection to 403 and 503
responses (or maybe exempt 200-series and 300-series responses).

These are a couple of sites that used customized CloudFlare:
https://4chan.org/ ("Verification Required")
https://yelp.com/ ("You're not barking up the wrong tree...")
yelp.com only started using CloudFlare a little while ago. It's a funny
case, because they *also* implement a hard Tor blacklist. Once you get
through the CloudFlare captcha 403, you get a 503 from a different
system.
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

Re: [tor-dev] Request for feedback/victims: cfc

[Yawning Angel]

[I hate replying to myself.]

On Wed, 23 Mar 2016 09:15:36 +
Yawning Angel  wrote:
> My "proof of concept" tech demo is what I consider good enough for
> use by brave people that aren't me, so I have put up an XPI package
> at: https://people.torproject.org/~yawning/volatile/cfc-20160323/

I noticed some dumb bugs and UI issues in the version I pushed so I
changed a lot of things and uploaded a new version that should be
better behaved.  In particular:

 * It is now Content Script based, and does IPC so it may survive the
   transition to sandboxed/multiprocess firefox better.

 * It will always inject a button into the DOM instead of trying to
   display browser UI stuff (content scripts are supposed to have
   isolation...).

   * The UI selection pref is removed.

   * The ask on captcha option for behavior is removed, since a button
 always will be there to bypass it.

 * Loading lots of pages that end up displaying street signs *should*
   now behave correctly.

The old release is under `./old` for posterity.

Sorry for the inconvenience,

-- 
Yawning Angel


pgpUUD0w2JeqL.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

[tor-dev] Request for feedback/victims: cfc

[Yawning Angel]

Hello,

Inspired by https://trac.torproject.org/projects/tor/ticket/18361
I've been working on way to improve the situation.

My "proof of concept" tech demo is what I consider good enough for
use by brave people that aren't me, so I have put up an XPI package
at: https://people.torproject.org/~yawning/volatile/cfc-20160323/

The source: https://git.schwanenlied.me/yawning/cfc (Requires the
Firefox SDK aka Jetpack to package).

By default the addon will:

 * Rewrite the CloudFlare captcha error page with messages that reflect
   my perception of reality[0].

 * Rewrite imgur ".gifv" links to ".gif".

Under "Tools->Addons->Extensions" you can configure the addon to:

 * Automatically fetch a cached copy of pages hosted on CloudFlare
   infrastructure from archive.is.

 * Automatically fetch a cached copy of pages that present a CloudFlare
   captcha from archive.is.

 * Pop up a UI widget asking if you want to fetch a cached copy of the
   page from archive.is each time you encounter a captcha.

 * Disable the snarky error message replacement (Requires a restart to
   take effect, because I'm lazy).

 * Disable the gifv URL rewrite.

TODO:

 * Support a user definable blacklist (eg: If you want to always use
   archive.is to access gawker.com or other clickbait bullshit, you
   should be able to easily do so).

 * Add more general quality of life things.

 * Think about making it work on Fenec (It currently will not because
   PopUpNotifications are handled differently, among other things).

 * Rewrite the internals to prepare for e10s.

WARNING:

 * If archive.is is evil, they can track you across page fetches
   trivially, because this sort of use case is outside of Tor Browser's
   current threat model (Yes, CloudFlare/Google can also do the same
   thing currently, who do you trust more?).

 * PEOPLE THAT HAVE BIG SCARY ADVERSARIES IN THEIR THREAT MODEL SHOULD
   NOT USE THIS.

If you don't know how to install addons given as XPI files, you
shouldn't be using this.  This is only tested on 6.0a4 (Linux/64 bit).
It *should* work on everything that isn't Orfox that's relatively
modern, YMMV.

Regards,

-- 
Yawning Angel

[0]: A very cynical/adversarial take on things.  Opinions are my own,
etc, and I don't care if you're offended.


pgpS7slMkLTl3.pgp
Description: OpenPGP digital signature
___
tor-dev mailing list
tor-dev@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev