Delivery-Date: Sat, 16 Jan 2016 16:46:48 -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 114A71E0CC0;
	Sat, 16 Jan 2016 16:46:47 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 70475239B0;
	Sat, 16 Jan 2016 21:46:43 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 93C702194D
 for <tor-talk@lists.torproject.org>; Sat, 16 Jan 2016 21:46:39 +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 toL8oWqCnfs4 for <tor-talk@lists.torproject.org>;
 Sat, 16 Jan 2016 21:46:39 +0000 (UTC)
Received: from trillian.krikkit.nl (trillian.krikkit.nl [94.142.240.21])
 (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits))
 (Client did not present a certificate)
 by eugeni.torproject.org (Postfix) with ESMTPS id 6546E20714
 for <tor-talk@lists.torproject.org>; Sat, 16 Jan 2016 21:46:39 +0000 (UTC)
X-Greylist: delayed 1410 seconds by postgrey-1.34 at eugeni;
 Sat, 16 Jan 2016 21:46:39 UTC
Received: by trillian.krikkit.nl with esmtpsa
 (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1aKYJH-0004Sb-6p
 for tor-talk@lists.torproject.org; Sat, 16 Jan 2016 22:23:06 +0100
Received: by ix-293.local (Postfix, from userid 501)
 id AC710C48E66; Sat, 16 Jan 2016 22:22:50 +0100 (CET)
Date: Sat, 16 Jan 2016 22:22:50 +0100
From: Rejo Zenger <rejo@zenger.nl>
To: tor-talk@lists.torproject.org
Message-ID: <20160116212250.GA14827@ix-293.local>
MIME-Version: 1.0
X-Trillian-Spam-Scanner: trillian.krikkit.nl
X-Trillian-Spam-Score: -0.0 (/)
X-Trillian-Spam-Score-Int: 0
X-Trillian-Spam-Report: result=No,
 score=-0.0 required=4.0 tests=NO_RELAYS version=3.4.0
Subject: [tor-talk] trusting .onion services
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="===============4909331043350752027=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>


--===============4909331043350752027==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="PEIAKu/WMn1b1Hv9"
Content-Disposition: inline


--PEIAKu/WMn1b1Hv9
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

I'm wondering...=20

 - How can a user reliably determine some .onion address actually
   belongs to intended owner?

 - How is the provider of .onion service supposed to deal with a lost or
   compromised private key, especially from the point of view from the
   user of this service? How does the user know a .onion-address has
   it's key revoke?

Let me explain...


One of the advantages of using a .onion address to identify the service
you are connecting to, is that you don't have to rely on a third party
as you would do in a system with Certificate Authorities. By relying on
the certificate signed by a trusted CA, the user can be sure the site he
is connecting to is actually belongs to a particular entity. With a
=2Eonion address that is no longer needed since those address are
self-authenticating. Sounds good.

Now, the problem I have is that the user doesn't have a reliable way to
determine whether a given address actually belongs to the site he wants
to visit. As far as I can tell, Facebook has two solutions to this: it
mentions the correct address in presentations, blogs and press coverage
wherever it can and its TLS-certificate mentions both the .onion address
as well as it's regular address (as Subject Alt Names).

So, the first solution can't be done by everyone, not everyone has that
much coverage. The second solution is nice, but falls back to the CA
system. Ironic, isn't it? [1]

Or, to rephrase it: how can a user reliably determine the .onion address
for a given entity without relying on the flawed CA system and without
the entity having a lot of visibility?


Given the fact that the hostname is a derivate of the private key used
to encrypt the connection to that hostname, there is a bigger issue when
the private key is stolen or lost (or any other case where the key needs
to be replaced.)

When the key is lost (yes, shouldn't happen, but shit happens), the
hostname changes. There is no reliable way for a user to learn what the
new key, and therefor the hostname, is.

When the key is stolen (or compromised in any other way), the key should
be replaced. This may be even more problematic than the case where the
key is lost, which would render the site unreachable. When the key is
stolen, the key may be used by an perpetrator. The problem: there is no
way to tell the world that a particular key is compromised. [2] The
administrator is able to make the site accessible via a new key and new
hostname, but the attacker may keep running a modified copy of the site
using the stolen key.



[1] Ironic, as Roger's blog on this topic makes clear there are all
kinds of reasons why we do not want re-enforce this system, partly
because it is flawed, partly because it costs money, partly because it
undoes the anonymity that some hidden sites need, partly because...

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

[2] OK. Not entirely true, maybe. It may be possible to include those
key in some listing of the directory authorities marking them as bad
nodes. This is a manual process.


--=20
Rejo Zenger
E rejo@zenger.nl | P +31(0)639642738 | W https://rejo.zenger.nl =20
T @rejozenger | J rejo@zenger.nl

OpenPGP   1FBF 7B37 6537 68B1 2532  A4CB 0994 0946 21DB EFD4
XMPP OTR  271A 9186 AFBC 8124 18CF  4BE2 E000 E708 F811 5ACF
Signal    05 EB 38 5C 01 0B 55 6A 19 69 E1 EF C2 99 89 EC 9C
          E4 88 3C 6F E3 7D 58 61 9B 32 E8 DB 9F ED 1B 2A

--PEIAKu/WMn1b1Hv9
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQJ8BAEBCgBmBQJWmrScXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxRkJGN0IzNzY1Mzc2OEIxMjUzMkE0Q0Iw
OTk0MDk0NjIxREJFRkQ0AAoJEAmUCUYh2+/Uxt4P/2VRsQ1Ov4YoZ45OdLSDTJso
NxRjoFcV/VFxw2WlaRyF7ACn0s2Ak0Az/rvKBPxddAhVU59Oe1Wk0OS7Sd2XF03T
bFVUdYuAjYbHmgu+/oVeVYz+DGQEipue0Svs0YjbIXkx1FqfE61IfwoIp19WdEo9
qXHWRv9xTHB0m4o9JMJ9NvbTf7Rx3Pc4UxB8hgUnxbQJS2vPqzw9e3n/j5hyOMEW
wuVh6XUXxjesCWaNcAgTmbKmksVxd2gy2p36LEpkvezvEfUmSXV8O85sLuGoSHca
ZXf6mMZrsuzGIwd91MBVyoopVa9qPTC94ZxQbacnW9sUYHtwmo9C3icQpQajx+BI
6C/h4UUta/8ZOVlRCNX8KMBQC5AnCOUmdM1WQ2FKhXcSHwWIk/aMW6McVO0UaMv6
OfuZ9DXaWlGisKvyH084Ob9L4r3xLBoGFLHfH8mGV92TrITtKu7O6Dx0jioaWEbI
nkPqsOFnFUoY0QNcQ4vXU+gR0EyxEJ5UJBakWKGWzrZW2TLoVy/5AKi/GFyQTuH2
TfPgs4PHUpI0tUksADXcv1RebjAcv9jC8mmzom8LdxkNaMnaqtE/Zu0wbpKFrO1t
MlVeYmu78X+gHZ2zH6N9oxFWGumxOR0MbiQvqS/Gx9e2L13fJc0ZF1FLhsSMAfPd
Wy3Nj9tscCP0RhaWKxy6
=0tcz
-----END PGP SIGNATURE-----

--PEIAKu/WMn1b1Hv9--

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

--===============4909331043350752027==--

