Delivery-Date: Mon, 18 May 2015 20:07: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 252BC1E02C4
	for <archiver@seul.org>; Mon, 18 May 2015 20:07:43 -0400 (EDT)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2D9C835072;
	Tue, 19 May 2015 00:07:39 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 5204435063
 for <tor-talk@lists.torproject.org>; Tue, 19 May 2015 00:07:36 +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 J7_Hb1wrkiuZ for <tor-talk@lists.torproject.org>;
 Tue, 19 May 2015 00:07:36 +0000 (UTC)
Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com
 [67.231.153.30])
 (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 1E95034E35
 for <tor-talk@lists.torproject.org>; Tue, 19 May 2015 00:07:36 +0000 (UTC)
X-Greylist: delayed 528 seconds by postgrey-1.34 at eugeni;
 Tue, 19 May 2015 00:07:36 UTC
Received: from pps.filterd (m0004060 [127.0.0.1])
 by mx0b-00082601.pphosted.com (8.14.5/8.14.5) with SMTP id t4INux0K019238
 for <tor-talk@lists.torproject.org>; Mon, 18 May 2015 16:58:45 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fb.com;
 h=from : to : subject : date
 : message-id : references : in-reply-to : content-type : mime-version;
 s=facebook; bh=Oc9i+tZtb9IHu3S6HOPRohMUNFR9pGyRCtHx+WgjKbE=;
 b=BEbooFBgMcZeqn1qvFejwRhMqEQrGw48iIWQZ9EtwpCgo1zfylpMpRg7GT3dTuY1QA2y
 67hV+QSb0ecSniOCV/mhWsf9GHI4qIcspqVSvvDvMibp2CyJIlaleOWvW/85hKGgJbfL
 jrmoSxwRKRRVYDd9LAjxUYlbr5GbcKG8fQU= 
Received: from mail.thefacebook.com ([199.201.64.23])
 by mx0b-00082601.pphosted.com with ESMTP id 1ufqpyghg8-1
 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
 for <tor-talk@lists.torproject.org>; Mon, 18 May 2015 16:58:45 -0700
Received: from PRN-MBX02-4.TheFacebook.com ([169.254.5.133]) by
 PRN-CHUB13.TheFacebook.com ([fe80::8c35:7ba8:bb32:ee09%12]) with mapi id
 14.03.0195.001; Mon, 18 May 2015 16:58:43 -0700
From: Alec Muffett <alecm@fb.com>
To: "tor-talk@lists.torproject.org" <tor-talk@lists.torproject.org>
Thread-Topic: [tor-talk] Making a Site Available as both a Hidden Service
 and on the www - thoughts?
Thread-Index: AQHQkKCWQyEiwmCnlUWOIfZbRgRBcJ2C4UEA
Date: Mon, 18 May 2015 23:58:42 +0000
Message-ID: <447D885D-B966-43F7-B491-19F9E829279B@fb.com>
References: <20150517112641-728-3379-mailpile@mailpile-home>
In-Reply-To: <20150517112641-728-3379-mailpile@mailpile-home>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
x-originating-ip: [192.168.54.13]
MIME-Version: 1.0
X-Proofpoint-Spam-Reason: safe
X-FB-Internal: Safe
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33,
 0.0.0000
 definitions=2015-05-18_04:2015-05-18,2015-05-18,1970-01-01 signatures=0
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: multipart/mixed; boundary="===============2901529741475411395=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

--===============2901529741475411395==
Content-Language: en-US
Content-Type: multipart/signed;
	boundary="Apple-Mail=_0F3A0932-CF70-41E6-ABB0-9614BF47C0B9";
	protocol="application/pgp-signature"; micalg=pgp-sha512

--Apple-Mail=_0F3A0932-CF70-41E6-ABB0-9614BF47C0B9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hello All!

Sorry I have not been able to get back to this thread until now, but I =
wanted to jump in with some observations, notes and a couple of =
corrections.

Given the length of the thread I shall try to be brief, though I shall =
also try to run chronologically from the start of the thread:


=3D=3D Kludging your onion site to use HTTPS? =3D=3D

There are a bunch of reasons to use HTTPS atop your onion site. The =
reasons could be addressed rationally, but to do so "properly" would =
require some combination of:

a) fixing all the browsers to understand "Onion >=3D SSL"

...and...

b) fixing all the CMSes to understand that "Onion >=3D SSL"

...both of which seem complicated, so instead so we went with the third =
option:

c) implement SSL over Onion, using a legitimate certificate.

This led to a bunch of benefits; see the "tor-tips" link below for =
extended details. (TL;DR - secure cookies, CSP, fewer legacy code =
mods...)


=3D=3D Duplicate Content Penalty Risk =3D=3D

Wow - this is a novel consideration that we missed! We effectively =
solved this by liaising with the Tor2web team (props!) eventually =
deciding that the best way to minimize crossover between the two =
universes was to block access to the Facebook onion site via Tor2web. =
This was announced by Tor2web here:

http://comments.gmane.org/gmane.network.tor.user/34292

- and the block is easy: Tor2web already issue an "X-Tor2web" header =
which you can detect, and then reject the connection with a helpful =
message. If you choose this route then the risk is mitigated somewhat.

Securedrop have done the same:

https://github.com/freedomofpress/securedrop/issues/43

Re: the suggested fix, yes one could certainly serve a different =
"robots.txt=E2=80=9D from the onion site - very cute idea! - but if you =
have users with logins then there is a MITM risk which is perhaps best =
reduced by separating the universes properly. Hence.


=3D=3D Faking an origin IP address =3D=3D

As observed elsewhere, we tell our infrastructure that any traffic =
inbound from the Facebook onion site is sourced from the DHCP broadcast =
network (169.254/whatever).

This is a hack which may or may not work for you, but it is sweet for us =
- 169.254 is an space "halfway down the stairs=E2=80=9D, having the =
advantage of being a non-routable network yet not in the RFC1918 address =
space that might be used/hardcoded elsewhere internally.

It also means that our anti-abuse mechanisms have an otherwise sane IP =
address to work with.


=3D=3D Javascript =3D=3D

I am very pleased to report that https://m.facebookcorewwwi.onion works =
fine with the latest Tor Browser Bundle in maximum-security, =
no-Javascript-required mode.


=3D=3D Relative URLs =3D=3D

Facebook generates a _lot_ of absolute URLs but we also mostly comprise =
dynamically-rendered content; traffic which comes from the onion site is =
tagged with a flag to denote that "when you are rendering a URL for this =
request, use the '.onion' address rather than the '.com' one".

The primary exception to this process is when you are stringifying a URL =
which is used to access an internal machine for the purposes of (say) a =
database lookup. You generally don't want to onionify those.

Software plug: XHP for dynamic PHP HTML rendering =3D Awesome Benefits.  =
https://github.com/facebook/xhp-lib


=3D=3D Redirections "offsite" from onion site to WWW site =3D=3D

Here's a cute idea which we haven't tried yet, but are considering: if =
you are running with "real" SSL on your onion site you can enable =
"Content Security Policy" (CSP)

http://en.wikipedia.org/wiki/Content_Security_Policy

=E2=80=A6and it may be possible to configure CSP on your onion site such =
that any link-clicks that go to your WWW/non-onion site are reported =
(via POST) to an onion endpoint, permitting you to (ideally) go fix the =
URL-rendering leak. Not tried it yet, though.


=3D=3D Sessions won't be transferable =3D=3D

Alas. But probably a good thing, see above re: Tor2web.


=3D=3D Analytics shows a single, heavily-trafficked IP, laden with =
badness =3D=3D

True, but actually... it wasn't so bad.


=3D=3D "Onion is better than SSL" =3D=3D

It does depend on your threat model, and if the threat model of your =
interlocutor is themed around "problems which are most intuitively =
solved by introducing a certificate authority", then I wish you courage, =
fortitude and patience. My position now is "why not have both?" - and I =
expend time trying to fix internet policy to permit both in the widest =
range of circumstances.

This strikes me as wise because Mozilla:

=
https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http/

...will soon be gating new features to work _only_ on HTTPS.


=3D=3D if someone connects to you from Tor, redirect them to the Onion =
=3D=3D

I recall Roger's comment in this blogpost, quote:

=
https://blog.torproject.org/blog/facebook-hidden-services-and-https-certs

<<< As an addendum to that optimism, I would be really sad if Facebook =
added a hidden service, had a few problems with trolls, and decided that =
they should prevent Tor users from using their old [...] address. So we =
should be vigilant in helping Facebook continue to allow Tor users to =
reach them through either address. >>>

=E2=80=A6where I subsequently commented:

<<< We currently see no benefit in intentionally blocking legitimate =
access via Tor exit nodes, not least because Tor exit nodes are publicly =
listed and easily identified and there appears to be little value in =
prioritising one form of Tor-sourced traffic over another. It is =
possible that this stance may change in future but I find it difficult =
to comprehend what benefit would come from doing so. >>>

...which still stands. Consider carefully any activity which might =
surprise people who access your site over Tor.

Perhaps a more autonomy-enhancing way to address this would be for Tor =
to big-up plugins which inform the user of their options?


=3D=3D Help! I am foo.onion but my static resources are www.foo.com! =3D=3D=


This is why the onion site for Facebook now uses subdomains; we have =
essentially modified our code to swap the ".com" address to the =
".onion=E2=80=9D one when stringifying any URIs that will be rendered by =
a browser.

The TL;DR here is that supporting "cdn.foo.onion" is hardly more complex =
than supporting "cdn.foo.fr" or "cdn.foo.de" in a consistent manner. We =
prune the rightmost two elements of the hostname and graft them with =
their onion equivalent quite efficiently; but see the database note =
under =E2=80=9CRelative URLs=E2=80=9D, above.


=3D=3D Scalability =3D=3D

Facebook runs three Onion addresses - Web, CDN and SBX - which mirror =
the Facebook TLDs on a (mostly) 1:1 basis.

We are currently running an experiment where each Onion address is =
implemented by two separate tor daemons (with the same key material) in =
separate datacentres. We're seeking failover functionality and increased =
functional bandwidth; this work is inspired in part by working with =
Ceysun Sucu and Steven Murdoch at UCL.

The results are really too early to draw any conclusions, but I think =
today=E2=80=99s observations are worth mentioning; two of the onion =
addresses are currently splitting their traffic about 60-40 between the =
two datacentres, whereas the third is more like 90-10. These proportions =
change over time. We plan some more tests to determine how long it would =
take a server failure to heal / migrate all traffic over to the other =
site.

We post operational status updates at:

https://www.facebook.com/facebookcorewwwi

...if you would like to follow along with what's happening.


=3D=3D Reducing 3 hops to 1 for a non-hidden onion site =3D=3D

I am working on this very sporadically. I'd welcome help, not only =
coding, but also in consideration of potential attacks (e.g.: ones =
comparable to DNS cache poisoning) which would be a nuisance to address. =
It would be unfortunate to trade speed for significant risk. Hat-tip to =
the Cloudflare team at the RWC conference in London earlier this year =
for poking me to consider this / related issues.


=3D=3D Risk of non-Tor browsers stupidly trying to DNS resolve .onion? =
=3D=3D

I'm collaborating with Jake/others regarding this:

https://www.ietf.org/id/draft-appelbaum-dnsop-onion-tld-01.txt


=3D=3D =E2=80=9COne thing: do you want to hide the origin server for the =
hidden service" =3D=3D

Oh, there are many, *many* more reasons to have an onion site for your =
website than just that. :-)

    - alec


* tor-tips: https://storify.com/AlecMuffett/tor-tips

=E2=80=94
Alec Muffett
Security Infrastructure
Facebook Engineering
London


--Apple-Mail=_0F3A0932-CF70-41E6-ABB0-9614BF47C0B9
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org

iQIcBAEBCgAGBQJVWny5AAoJECldTB9TIAHGUX4P/ifmlygSyw36YnhvW91T1CeX
gx5fQbNs9ONQkFV5uQe4GFrXwE4Viyaa4f8pW/XgdgCsQNusT3tuxE8vmUxbTOnu
zuCJNDaOLdSCYTgmTyjSG+MNdIId2X6LmsGjtSXrTTZaOdJhGfKobLtzKo+3ZKvb
RsbNh37/R88T8P9elOw7Ij89Y0JF+QzSbH4zminSJVfuSUsZJUbD1fMK8yAzLy9m
thKtm7YauyZlVuQgG8HjNFHFi3d9PmSR5jDpqqCc5y593+s0wWbtC8fD77U3YvWe
uafTH+nCB4bHf92iMKweCxpVS3IUD3udOTKUZg/fYdT8BAGN2PVRjbmPP7GlZ72C
7AsPvCRYQWlWB/zrcVNHoGhKsn9MZOo2x4RmOfso2SZzxC9JGDl3GcYHv6UshkQr
HeSk6S+TPZvxbz59TXCoOg55+fdEqNjqboX9DzJO/t75tZyt/BqrOZHKAkartThf
LBro66MCd5Xgq67wWhVhZ0BsS40vA5ii1gg3eJRHCkwha1ahjzYaEEQj4kthRmkU
B1zJ7YjGoUF4HilcyFzmVugpa7yr6C6EC8AufOoAIIzDLSzbTtT3kvD+uArovtOh
lp6GXpuVpdQyJaR9JbmFlfDxTvU49Vp+yUwOWXVywHQSJPs17Vtk2sc50lqGCtXT
YgjBzHqEo3lAbH+xkl1I
=BGYL
-----END PGP SIGNATURE-----

--Apple-Mail=_0F3A0932-CF70-41E6-ABB0-9614BF47C0B9--

--===============2901529741475411395==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

-- 
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

--===============2901529741475411395==--

