Delivery-Date: Thu, 31 Mar 2016 14:58:45 -0400
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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,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 7EC201E0B86;
	Thu, 31 Mar 2016 14:58:43 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A972139B6A;
	Thu, 31 Mar 2016 18:58:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id AFEED39AF6
 for <tor-talk@lists.torproject.org>; Thu, 31 Mar 2016 18:58:35 +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 Md2sZ3vL7juu for <tor-talk@lists.torproject.org>;
 Thu, 31 Mar 2016 18:58:35 +0000 (UTC)
Received: from mail-io0-x234.google.com (mail-io0-x234.google.com
 [IPv6:2607:f8b0:4001:c06::234])
 (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 7FE23360F7
 for <tor-talk@lists.torproject.org>; Thu, 31 Mar 2016 18:58:35 +0000 (UTC)
Received: by mail-io0-x234.google.com with SMTP id q128so123039719iof.3
 for <tor-talk@lists.torproject.org>; Thu, 31 Mar 2016 11:58:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google;
 h=mime-version:reply-to:in-reply-to:references:from:date:message-id
 :subject:to; bh=T5Un32X9Fr8936ksUsYiZOlfkZsp3j6+PWrBcWUPuZE=;
 b=le3QAYsjTBV7abHZkAVM838lfvEQ9PDTTS1vz/oI0FUEZD8/qmTT6ZVg2v3iHfeZt8
 7yehYad6PhC8HfOsF5bSUdYs+FSiN3E1BGHArD12jPWMe/Dd6VtlWHPrynsHCDvk4lGv
 gFFrpFa0EoRwgxRb+g1MuepKjH/UtpYZAZmU8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20130820;
 h=x-gm-message-state:mime-version:reply-to:in-reply-to:references
 :from:date:message-id:subject:to;
 bh=T5Un32X9Fr8936ksUsYiZOlfkZsp3j6+PWrBcWUPuZE=;
 b=Gloy5d0bV8qOXk8r2/ZxBNJ/xIM+lMFfcfZZEdicfKgNNXUFPjk1thi5/AEWRZ4D8B
 2EaTRqqYp+7L+PL8mJSUSi05bX1igA4kTnLTF5NNJqIRBCdvpY4iXveGmrcvOA16rGT8
 QXjFKAS7mpQ2FajBh+KSVy9SMXkfWwYdfe71Ty5lBNl1hoMm2+j8L+F5otcq79qFWW1X
 0H1ecRCimXMZZuIRq0glWvYTVDoFCnmo/OTue0K5QJAzqXOKtPoipi4VmTzCSl/Pphqt
 tb9u02MJxKyUqXSMKsJF1+Gbj8AJnPGhwceazedNv7OeQVF387AOFW/WMFSWTW1XvzZf
 8QOg==
X-Gm-Message-State: AD7BkJI4DHP707rzg0swdX64ayyEfx813Wnzny27vnjhZXE/tXOkpwPQTWehJUXkb0X3L3REoyCFdbOLK1gMbgkb
X-Received: by 10.107.159.137 with SMTP id i131mr839188ioe.29.1459450712677;
 Thu, 31 Mar 2016 11:58:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.79.21.199 with HTTP; Thu, 31 Mar 2016 11:58:13 -0700 (PDT)
In-Reply-To: <20160331180435.GA20480@inner.h.apk.li>
References: <20160330132105.GA8024@lapsedordinary.net>
 <20160330150151.GD3164@riseup.net>
 <56FC34BD.9070808@gmx.com> <20160331052504.GA13693@inner.h.apk.li>
 <56FD4FEC.1040903@gmx.com> <20160331180435.GA20480@inner.h.apk.li>
From: Greg Norcie <gnorcie@cdt.org>
Date: Thu, 31 Mar 2016 14:58:13 -0400
Message-ID: <CAMJgV7bJLnhqK+9N8x7rUrH4_Kzof58hZsVpTy6BhZkROyoZYg@mail.gmail.com>
To: tor-talk@lists.torproject.org
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] CloudFlare blog post
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>
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>

So the post seems to weigh heavily towards proof of work in Tor Browser,
rather than running .onion sites. (Which apparently attract less malicious
traffic? Interesting tidbit)

My question: why not simply move to using SHA-256? The main point in the
blog seemed to be that that using .onion sites is not workable due to the
use of SHA-1. Since the Tor Project has limited resources, it seems like
switching hashes and asking websites to use .onion addies would create less
work for the devs but have a similar effect to a proof of work module in
Tor Browser.

However, I may be missing something important, and if so please feel free
to enlighten me :)


/********************************************/
Greg Norcie (norcie@cdt.org)
Staff Technologist
Center for Democracy & Technology
District of Columbia office
(p) 202-637-9800
PGP: http://norcie.com/pgp.txt



*CDT's Annual Dinner (Tech Prom) is April 6, 2016.  Don't miss out!learn
more at https://cdt.org/annual-dinner <https://cdt.org/annual-dinner>*
/*******************************************/

On Thu, Mar 31, 2016 at 2:04 PM, Andreas Krey <a.krey@gmx.de> wrote:

> On Thu, 31 Mar 2016 11:27:24 +0000, Joe Btfsplk wrote:
> ...
> > >What I wonder is how they want to make a difference using .onion
> addresses
> > >for their customers - tor crawlers can take that redirect just so.
> > Andreas, sorry - don't understand part of your comment.
> > "It would be quite a lot of effort to do... *what?*... this way... -
> > sorry, it won't work any better."
>
> They said that automatically providing cloudflared sites with
> onion addresses would make it easier to detect nonmalicious
> tor use, but I wonder why they expect that the bad guys don't
> immediately use the onion instead of the plain site as well.
>
> ...
> > I've seen Cloudflare on low value target sites, like wood screw mfg info
> > sites & similar.  Unless other screw mfgs are sabotaging them, I doubt
> > much malicious activity is directed at such sites.
>
> This is simply the default setting, I guess. CF isn't just
> a abuse shield, it is first a CDN. There are sites where
> there is nothing relevant to harvest, and there are sites
> where there is, but they all use couldflare for different
> reasons, and get the scraper protection for free, and not
> necessarily on their intention.
>
> > 94% is saying essentially ALL Tor traffic / requests are "per se"
> > malicious or use inordinate amt of resources.  That leaves me & 6% of
> > users that aren't.
>
> Users != Traffic.
>
> > Maybe ? he's counting crawler *individual* requests - page by page - as
> > malicious?  They might make many more requests than real users, thus the
> > 94% claim?
>
> Quite probably.
>
> ...
> > His statement(s) & reasoning about blocking Tor still seem strange.  As
> > they say, "follow the money trail."  "Money trumps all other reasons /
> > motives."
>
> Tell that the authors of the software this mailing list is for.
>
> > I still say trackers aren't going to pay sites for TBB traffic. Don't
> > say, "You're using Tor - get lost" - bad for public relations.  Instead,
> > play dumb & covertly discourage (some) Tor users  - so they access the
> > site w/ unhardened browsers.
>
> Tracking is not cloudflare's business, it's the business of the site owner.
>
> > Can't sites tell the difference in actions of crawlers & real users?
>
> Not as easily as just using cloudflare as a front. Heck, my colleague
> has cloudflare in front of one of his sites, even though there was
> probable more traffic for setting that up than the site on a good day.
>
> > I'm sure some use browsers other than TBB for crawling & malicious
> > activity.  Can't sites block / time-out crawlers from continuing to
> > access entire site, once it becomes apparent - regardless of which
> browser?
>
> Yes. That would lock out the entire exit, and with the crawling
> density this apparently basically never gives tor users access.
>
> This is also what cloudflare does, just over longer time, and
> giving a captcha instead of an reject.
>
> > I get "time outs" from making 2 very narrow term searches in < 2 min. or
> > so, on some sites I'm registered on & participated - for a long time.
> > Why can't sites do the same w/ crawlers' rapid, repeated requests?
>
> Crawlers would immediately get smart and stretch their requests out?
>
> Andreas
>
> --
> "Totally trivial. Famous last words."
> From: Linus Torvalds <torvalds@*.org>
> Date: Fri, 22 Jan 2010 07:29:21 -0800
> --
> 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
>
-- 
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

