Delivery-Date: Sun, 17 May 2015 15:49:38 -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 AD6B91E0377
	for <archiver@seul.org>; Sun, 17 May 2015 15:49:35 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id CD52935228;
	Sun, 17 May 2015 19:49:32 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 7E6923521E
 for <tor-talk@lists.torproject.org>; Sun, 17 May 2015 19:49:29 +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 NgNPoaKDA7ce for <tor-talk@lists.torproject.org>;
 Sun, 17 May 2015 19:49:29 +0000 (UTC)
Received: from gerbil.it (unknown [107.6.175.158])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 3447134E50
 for <tor-talk@lists.torproject.org>; Sun, 17 May 2015 19:49:29 +0000 (UTC)
Received: from mailpile.local (localhost.localdomain [127.0.0.1])
 (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by gerbil.it (Postfix) with ESMTPSA id 830B61C27C13;
 Sun, 17 May 2015 14:49:24 -0500 (CDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gerbil.it; s=default;
 t=1431892165; bh=1qdx331WJohWe1kI//Y+omN6ja/PC3umhltAQLNVPYk=;
 h=Subject:From:To:In-Reply-To:References:Date;
 b=huRH+d+dCRfnt8wywawVafjo65NJLaIu/sOpjFEfypPmWjuwsIS2vUg5JnWdvr2lh
 18JurBh4RD8Dl5ploO51As1U16XIfRG8DR+xUHyLYxRNtUjl3EXBDNOvG/mIkvQwG0
 vN0mhcmfymWe7UjLPXjY209W933QMmX9C81lpgPk=
MIME-Version: 1.0
From: Ben <ben@gerbil.it>
To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
In-Reply-To: <20150517191201.GG7800@moria.seul.org>
References: <20150517191201.GG7800@moria.seul.org>
Date: Sun, 17 May 2015 18:46:53 -0000
Message-Id: <20150517184628-728-27034-mailpile@mailpile-home>
OpenPGP: id=1F9164D62373F057DF3971567F57C6686ACBCC6D; preference=signencrypt
X-Content-Filtered-By: Mailman/MimeDel 2.1.15
Subject: Re: [tor-talk] Making a Site Available as both a Hidden Service and
 on the www - thoughts?
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>


Hi all,

Thanks for your input!

> I'll try and update https://storify.com/AlecMuffett/tor-tips later with some thoughts.

I'll confess to finding storify pages quite hard to follow at times, but
there's definitely some food for thought in there. Will try and give it
a fuller read a little later

> On the other side CAs should give out certificates for .onion freely
> since only the owner of the private key can make any use for it.

I can think of some nastiness you could probably do if you could get
malware onto a target's machine, and they were connecting via a tor
router (or similar) rather than using SOCKS, but we're getting into a
few if's and but's there (plus, if you've got malware onto their
machine, there are better ways :) )

> But it's insulting to the superior concept of public-key based routing that the 
> certification industry is involved in any way at all.

I agree, but I suppose that we (as an industry) have spent so long
telling people they can't trust a site if there's no 's' that we
probably can't complain too much about people asking for HTTPS.

> When running a HS you don't get *any* clue where the circuit is coming
> from so the off-the-shelf protections may fail.

Yup, basically the scenerio I was envisaging there was that Bob tries to
hammer the site with SQLi and get's "his" IP banned. That IP, of course,
being the IP of my tor client (so, localhost). Alice then comes along
for an innocent read and gets presented with a page telling her she's
been banned.

To be fair, the IP based bans don't offer any protection against skilled
(or very patient) attackers. If you've got an exploit that the protections won't pick up on, you only need the one request - whether that be after a ban has expired (or an IP change) or the very first request you place.


> Tor users may be bothered by *others* seeing their activities, not
> necessarily you. They may be choosing to use the hidden service simply
> to have a better guarantee they are talking to nobody but you. To be
> sure no BULLRUN or other HTTPS MITM has any chance of playing out its
> cards.
>
> Also Tor users may be using more secure Internets by default or habit,
> but still welcome doing business with you. I probably would.

I hadn't actually thought about it in those terms, but you're right.
Maybe blocking off the shop section isn't quite as easy a decision as I
thought.

>> Basically, care would need to be taken to make sure readers aren't
>> accidentally directed off the HS and onto the www site.

A thought that's occurred to me on this one - currently most static
resources are referenced from a subdomain so that the browser can
parallelise a bit more (the setup is much the same way you might push
static resources to a CDN). 

So something's going to need to change there, otherwise you'll be
hitting foo.onion and then requesting static resources from
static1.example.com

That's handled by a plugin at the moment, so my initial thoughts on
working around that are:

Have the reverse proxy include an additional request header (e.g.
'X-ima-onion-user') and then hack on the plugin so it behaves differently if that header is present (either use a second .onion or make sure the references are relative).

Will also need to take that into account if I ever decide to have the
existing reverse proxy in front of the site cache responses.


>> Anyone have any thoughts of what else there is to trip up on?
>
> Scalability may become an issue.

Scalability is definitely my next challenge to think about. One thing
I've scratched down to come back and consider is whether it might be
setting up a (slightly weird) load balancing solution along the
following lines

You -> foo.onion (load balancer)
foo.onion -> 301 bar.onion

Where bar.onion is a mirror, so you might also end up being redirected
to jay.onion. One thing that concerns me about that is the number of
URLs you might end up with (if you hit bar.onion and then post the link
somewhere, what  if I take bar.onion out of service?).  

I'm working on the assumption there that Tor is the bottleneck, of
course, if that can be discounted then it should simply be a reverse
proxy with multiple origins configured.

Will give it some more thought at some point


> Another idea (hat tip to Blockchain.info support) is you can take the visitor's IP address, 
> and at the time of connection, check the list of tor exit nodes (somewhere like here: 
> https://check.torproject.org/exit-addresses ), and if it matches, redirect them to your 
> own .onion site.

That I like as an idea. Does anyone know if Tor Browser warns when
redirecting from a HTTPS site to HTTP (which is how it'll view it). I
know IE historically has, but have just realised I don't know with
Firefox/TB. Might have to check later.


> Don't forget the "decreasing load and reliance on exit relays" benefit,
> in case we arrive in that dismal future where it grows increasingly hard
> to operate exit relays in a diverse and well-dispersed set of locations.

Yes, that definitely struck me as a benefit. Don't think anyone will
notice my traffic drop off the exits, but if enough people set something
similar up, it could potentially be a good saving


Looks like I've some building/testing to do over the next couple of days
then - should keep me out of trouble for a bit 
-- 
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

