[tor-talk] A multi-layer proof of work system to solve the Tor/CloudFlare problem?

Fabio Pietrosanti (naif) - lists lists at infosecurity.ch
Sun Jan 24 11:19:57 UTC 2016


Hello,

following a discussion on Twitter on Tor and Cloudflare, i tried to
rationalize a possible multi-layer approach for fixing that issue by
leveraging Proof of Work.

Let's first try to define a couple of points:

1) The issue of Tor, on behalf of Tor users, with cloudflare is a
usability problem (because of the annoying captcha, requiring a user
interaction)

2) The issue of Cloudflare, on behalf of Cloudflare customer, is a
security problem due to "automated scans"


If we focus on mitigating the impact of those 2 problems in a general,
but automated way, we're done.

I'd propose to fix those issue by using Proof of Work systems, to be
independently implemented at Tor-side and Cloudflare side.



Tor could implement a Proof of Work system, to require any Tor client
establishing a new circuit and/or making a new TCP connection, to make
some math computation that's heavy on the client but light to be checked
on the Tor Exit Relay.

That way a normal web client, normally browsing a website, would not be
impacted from end-user experience, but any automated system (the ones
causing problems to Cloudflare) would get hit by a huge increase in the
computational resources required to make such massive attacks.

That would change the balance of effort/results of anyone using Tor to
make automated and massive scan on the internet, because it would be
*computationally expensive*.

This would require to implement the system within the OR protocol with a
specific proposal, identifying all the performance improvement issue to
minimize (or avoid) any end-user experience impact, with everything done
automatically by the Tor client and Tor Server.

Now, assuming that what has been define above is working properly and
it's effective, the Tor network should see a strong decrease in the
amount of "automated and massive attacks" being done trough it's Exit
Relays.

At that stage Cloudflare, instead of using a Captcha, could also
implement an independent Javascript Proof of Work system, to be applied
at Application Level and run on Tor Browser, providing an amount of
computation effort, proportionate to a threshold measuring the amount of
automated attacks coming from Tor network/over time, but always giving a
nice looking UX progress bar with "Please wait X seconds..."

PoW at browser-level is nice, because the user doesn't have to do any
kind of interaction, but just look at the screen indicating that he have
to wait some seconds, with a nice progressbar moving on.

On Cloudflare side they could have an indicator/threshold on "how much
automated attacks" are happening at a given time from Tor network
measured on a "period of observation".
Depending on those parameter, they could increase the
client-side-pow-computation-time, de-facto increasing the costs of
automated scanning cloudflare with the increase of automated scanning,
increasing dynamically the resources of the attackers with the increase
of his aggressivity.

Ie: "Under a low-normal amount of automated attack from Tor network" the
Pow may require just 3 seconds of computation, but under "medium-high
amount of attacks from the Tor network" the Pow may require 8 seconds of
client-side computation.

Maybe it's a bad idea, but the key to be addressed is imho:
- reducing the automated attacks from Tor netwok by increasing it's
costs while leaving intact the end-user experience on Tor Browser
- having cloudflare to implement application protection system that does
not require user interaction (ie: Pow in place of captcha)



-- 
Fabio Pietrosanti (naif)
HERMES - Center for Transparency and Digital Human Rights
http://logioshermes.org - https://globaleaks.org - https://tor2web.org -
https://ahmia.fi


More information about the tor-talk mailing list