Delivery-Date: Sun, 24 Jan 2016 06:20:12 -0500
Return-Path: <tor-talk-bounces@lists.torproject.org>
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on moria.seul.org
X-Spam-Level: 
X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	T_RP_MATCHES_RCVD autolearn=ham version=3.3.1
X-Original-To: archiver@seul.org
Delivered-To: archiver@seul.org
Received: from eugeni.torproject.org (eugeni.torproject.org [38.229.72.13])
	(using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits))
	(No client certificate requested)
	by khazad-dum.seul.org (Postfix) with ESMTPS id F14381E034F;
	Sun, 24 Jan 2016 06:20:09 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 0E47F3621A;
	Sun, 24 Jan 2016 11:20:08 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 1099631F16
 for <tor-talk@lists.torproject.org>; Sun, 24 Jan 2016 11:20:04 +0000 (UTC)
X-Virus-Scanned: Debian amavisd-new at 
Received: from eugeni.torproject.org ([127.0.0.1])
 by localhost (eugeni.torproject.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 1pfpKXT0J3iB for <tor-talk@lists.torproject.org>;
 Sun, 24 Jan 2016 11:20:04 +0000 (UTC)
Received: from mail-lf0-f97.google.com (mail-lf0-f97.google.com
 [209.85.215.97])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (Client CN "smtp.gmail.com",
 Issuer "Google Internet Authority G2" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id B379428441
 for <tor-talk@lists.torproject.org>; Sun, 24 Jan 2016 11:20:03 +0000 (UTC)
Received: by mail-lf0-f97.google.com with SMTP id m198so5435337lfm.3
 for <tor-talk@lists.torproject.org>; Sun, 24 Jan 2016 03:20:03 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:to:from:subject:message-id:date:user-agent
 :content-type:content-transfer-encoding;
 bh=alZhBkLqBSnQIXQV1JgV3wa4iOD63aI/N++vvWxUhG4=;
 b=DEWa5GOQQ1jJbAgk9hft2vTRtZvNzmTFzR6nYWLYe20TXLWMnWJHtcMPmSb40GuYP3
 YQgukpT8Iz5bPbtTpx6zdvdOgFcnjXyTSqvKD+HySaw3lTpM8bdLIMhMu0KpenqmSirS
 wTbPM3kx4izzCb3s/UVePsNpXwhXXUajdgJ9pSUCbzeLebs66lnl9h0MdMzqu/DZeW2V
 7kKo6Q7XB3t9iapD4gI00Eq2/mVkzW/BySHoOKckB/huJKUKKlsx9wq1UO0vPX1ocZ35
 RpkFWfu7QQB8nLYUROBBOhn5JwU3d6MkfhlufHE3L8lfSMuI6Gwo+xhqs32EOqeukqRe
 Xj8w==
X-Gm-Message-State: AG10YORG2Zl70htNHLboukM7OwfPSebMUs14VSRKBFlcrroEcD0UXLFT6nszGJ5bz20HFhQNHnrq6qjI9F9foge6m+go32eq
X-Received: by 10.28.212.9 with SMTP id l9mr13342693wmg.75.1453634400170;
 Sun, 24 Jan 2016 03:20:00 -0800 (PST)
Received: from apps.globaleaks.org (demo.globaleaks.org. [194.150.168.64])
 by smtp-relay.gmail.com with ESMTPS id z139sm845456wmz.0.2016.01.24.03.19.59
 for <tor-talk@lists.torproject.org>
 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
 Sun, 24 Jan 2016 03:20:00 -0800 (PST)
X-Relaying-Domain: apps.globaleaks.org
To: tor-talk@lists.torproject.org
From: "Fabio Pietrosanti (naif) - lists" <lists@infosecurity.ch>
X-Enigmail-Draft-Status: N1110
Message-ID: <56A4B35D.4060606@infosecurity.ch>
Date: Sun, 24 Jan 2016 12:19:57 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.1
Subject: [tor-talk] A multi-layer proof of work system to solve the
 Tor/CloudFlare problem?
X-BeenThere: tor-talk@lists.torproject.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: tor-talk@lists.torproject.org
List-Id: "all discussion about theory, design,
 and development of Onion Routing" <tor-talk.lists.torproject.org>
List-Unsubscribe: <https://lists.torproject.org/cgi-bin/mailman/options/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=unsubscribe>
List-Archive: <http://lists.torproject.org/pipermail/tor-talk/>
List-Post: <mailto:tor-talk@lists.torproject.org>
List-Help: <mailto:tor-talk-request@lists.torproject.org?subject=help>
List-Subscribe: <https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk>, 
 <mailto:tor-talk-request@lists.torproject.org?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

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
-- 
tor-talk mailing list - tor-talk@lists.torproject.org
To unsubscribe or change other settings go to
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

