[tor-access] Predicting effectiveness

[Mike Perry]

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
-------------- 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/20161007/292644c6/attachment.sig>