[tor-access] Predicting effectiveness

John Graham-Cumming jgc at cloudflare.com
Sat Oct 8 16:56:00 UTC 2016


We already started that filtering approach. It's live for millions of web sites (although not all sites using Cloudflare) and has been for some time. It has resulted in a large drop in the use of CAPTCHA.

I was waiting to report to this group the results as I wanted to let it run for a while so we can see how well the abuse filtering works. But it's just fine that you mention is now. 

I'm very interested in the problem of filtering abusive Tor traffic because the Tor system is unique in its approach to privacy making it a challenge to filter well. This is an interesting engineering problem and has great benefits for us as being good at filtering abusive traffic from Tor makes us better at filtering abuse from the wider internet. 

John.


> On 8 Oct 2016, at 00:17, Mike Perry <mikeperry at torproject.org> wrote:
> 
> John Graham-Cumming:
>>> On Tue, Oct 4, 2016 at 4:15 AM, Jeff Burdges <burdges at gnunet.org> wrote:
>>> 
>>>> On Mon, 2016-10-03 at 20:28 +0100, John Graham-Cumming wrote:
>>>> 1. Benign GET / repeated 1000 times per second. That's a DoS on
>>>> the server
>> 
>>> Are these serious concerns?  I suppose they're more serious than the DoS
>>> concerns, so that sounds bad from the token stockpiling perspective.*
>> 
>> Yes, these are serious concerns. If they weren't I would have just dropped
>> CAPTCHA for Tor exit nodes and be done with it. We know from watching
>> attacks come through Tor that to do so would expose people's web sites.
> 
> Hey John, at the CloudFlare Internet Summit, we spoke briefly about your
> efforts to work on a WAF-based approach for actively filtering out
> obviously bad requests, letting through obviously good requests, and
> then using this blind signed token scheme for the requests that were
> difficult to tell for whatever reason.
> 
> I am still convinced that this combination (or something like it) is the
> winning solution here, especially given what Georg pointed out about it
> being difficult for us to store tokens for very long (depending on user
> behavior, New Identity usage, and if they want to store disk history or
> not). On top of that, with concerns about token farming/hoarding and the
> need to expire keys/tokens somewhat frequently on CloudFlare's side, I'm
> not seeing a terribly high multiplier/CAPTCHA reduction for the tokens
> by themselves.
> 
> But I still do see a potentially high multiplier effect if we can do
> better on request filtering, and also add the crypto on top of that,
> even if the Tor Browser defaults work against us somewhat.
> 
> It sounded to me like you folks were really close to the WAF approach
> working. Can you say if that is still the case, and what timelines we
> might expect?
> 
> 
> P.S. I hope I'm not stealing your thunder by talking about that project,
> but I know it made me a lot less skeptical of the blind token idea as a
> whole, and I suspect others here would also be comforted by that news as
> well. Knowing that general trajectory would help everybody get closer to
> being on the same page with this, I think :)
> 
> 
> -- 
> Mike Perry
> _______________________________________________
> tor-access mailing list
> tor-access at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-access
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-access/attachments/20161008/610f7572/attachment.html>


More information about the tor-access mailing list