Delivery-Date: Sun, 28 Feb 2016 16:59:40 -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 E69A01E0682;
	Sun, 28 Feb 2016 16:59:38 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 4743D3A05F;
	Sun, 28 Feb 2016 21:59:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 6DC193A062
 for <tor-talk@lists.torproject.org>; Sun, 28 Feb 2016 21:59:30 +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 RKUT_Udmc6QN for <tor-talk@lists.torproject.org>;
 Sun, 28 Feb 2016 21:59:30 +0000 (UTC)
Received: from mail.witmond.nl (mail.wtmnd.nl [80.100.189.3])
 by eugeni.torproject.org (Postfix) with ESMTP id 15D513A056
 for <tor-talk@lists.torproject.org>; Sun, 28 Feb 2016 21:59:30 +0000 (UTC)
Received: from [IPv6:2001:980:71b2:1::6] (unknown [IPv6:2001:980:71b2:1::6])
 by mail.witmond.nl (Postfix) with ESMTPSA id 7E6B0C0174;
 Sun, 28 Feb 2016 21:53:18 +0000 (UTC)
Message-ID: <56D36C49.7090605@witmond.nl>
Date: Sun, 28 Feb 2016 22:53:13 +0100
From: Guido Witmond <guido@witmond.nl>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:31.0) Gecko/20100101 Icedove/31.8.0
MIME-Version: 1.0
To: tor-talk@lists.torproject.org, 
 "rejo@zenger.nl >> Rejo Zenger" <rejo@zenger.nl>
References: <20160116212250.GA14827@ix-293.local>
In-Reply-To: <20160116212250.GA14827@ix-293.local>
Subject: Re: [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="===============1349561326490053717=="
Errors-To: tor-talk-bounces@lists.torproject.org
Sender: "tor-talk" <tor-talk-bounces@lists.torproject.org>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============1349561326490053717==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="51qNAEgKUrCjQrm0xhPoQPO3nhkkvhuJS"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--51qNAEgKUrCjQrm0xhPoQPO3nhkkvhuJS
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On 01/16/16 22:22, Rejo Zenger wrote:
> Hi!
>=20
> I'm wondering...=20
>=20
>  - How can a user reliably determine some .onion address actually
>    belongs to intended owner?

Hi Rejo,

I think that in general, .onion addresses are unauthenticated. That is,
there is no way of determining who an address belongs to.

All we know of an .onion address is that its tied to whomever holds the
private key. And given the risk of disclosure of the private key, all
bets are off. This is also true of GPG, where an adversary can create a
clone key bearing my name but their key. Erinn Clark of the Tor Project
has been a victim of such an attack.

In my pet project I'm using Hidden Services as a means for people to
connect to each other. One person opens a HS, send the onion address to
another in an encrypted message. The other connects to the service. Then
BOTH people authenticate to the other with their already exchanged keys
before their software lets the data flow commence. Knowledge of the
onion address or even having a copy of the private key won't get the
connection started.

In short, I built an authentication layer on top of hidden services.

That authentication layer uses PKI certificates and stuff to distribute
public keys to each other. And ultimately, the same issue reappears:
Whom am I talking to? And with risk of disclosure of the private key,
all bets are off.

I believe this to be a fundamental property of cryptography. The eternal
uncertainty of the identity of the other party. The more anonymous the
key exchange the higher the uncertainty. In other words: the higher the
need for secrecy and anonymity, the greater the uncertainty.

The answer you are looking for is to determine how much of a risk there
is with plain onion asdresses, or what extra authentication and
repudiation you need to build on top. And how much deanonymisation you
are willing to accept.

I believe it's ultimately a design trade off.


With regards, Guido Witmond.


>  - How is the provider of .onion service supposed to deal with a lost o=
r
>    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?
>=20
> Let me explain...
>=20
>=20
> 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 h=
e
> is connecting to is actually belongs to a particular entity. With a
> .onion address that is no longer needed since those address are
> self-authenticating. Sounds good.
>=20
> 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 addres=
s
> as well as it's regular address (as Subject Alt Names).
>=20
> 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]
>=20
> Or, to rephrase it: how can a user reliably determine the .onion addres=
s
> for a given entity without relying on the flawed CA system and without
> the entity having a lot of visibility?
>=20
>=20
> 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 whe=
n
> the private key is stolen or lost (or any other case where the key need=
s
> to be replaced.)
>=20
> 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.
>=20
> When the key is stolen (or compromised in any other way), the key shoul=
d
> 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.
>=20
>=20
>=20
> [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...
>=20
> https://blog.torproject.org/blog/facebook-hidden-services-and-https-cer=
ts
>=20
> [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
>=20
>=20
>=20



--51qNAEgKUrCjQrm0xhPoQPO3nhkkvhuJS
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJW02xKAAoJEHPd8GglaNRmwP4QAJCA6WF2DOychf1rFRUr8A4r
CcJjpnRwPjl0UFekKMzL47iRdME+267YPDbL6WY9LFqoOVKg0GsaQq/5ZmkWjSak
KhWjyKyT47/HgoaTVsyunmWgtjfyarv9wptJxewI0zrY8OigCbfh2LKjuuYXiPpu
70TfPca/zBaOY5/KF+RvbgQ+o1LVmzlBO2Vfws04RVy+RwC4W0E/BGGYZeAUbMtE
jl9K1oY6zrmNdbygfmI/P7tF3c1urztxr4R3ISR1QpGrra/JjeWV/tV9t71d8Uuy
OzpAAdY2cZWp1WxedSXhG4YeuN8GkCuMtwJlCS/hN8Ra5r3E3sy+Wbl3cvdRuvEp
gKoGz5dHYidgxQkO1XghmjptmLtcwQgnQlu5tTXwLuAlWytCeUKZeWFmhYIjrb6F
nVFl0ar9tfJGZgd6AtdAhWH3E8bVUDNOOc2yZaS+DicQkRyTRR8lBVfnYpH1EAxe
UdCxBEayuBNmK0Gx2q7onL42prd6sJXwEgaZHPYbQ7oynwSfuKyRAlY+vymUyPeU
Sky+5UFNMyBa8url6WGRl83X4AJFPDjGe0XX2CteQP8CQ94WGdRMaYYVAMB5jevv
F1ggDKUsd8FO01zc/4eg9yy9yixDCyXiSdR4G01tnBctnP1K4UKUWipceFdsD0Fk
q/3EPgcAfHRbILMSHdIg
=G0Fk
-----END PGP SIGNATURE-----

--51qNAEgKUrCjQrm0xhPoQPO3nhkkvhuJS--

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

--===============1349561326490053717==--

