Delivery-Date: Sat, 16 Jan 2016 17:20:54 -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.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	RCVD_IN_DNSWL_MED,T_DKIM_INVALID,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY
	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 A061C1E0D13;
	Sat, 16 Jan 2016 17:20:52 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id 2A5FE24218;
	Sat, 16 Jan 2016 22:20:48 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 07E2E220EE
 for <tor-talk@lists.torproject.org>; Sat, 16 Jan 2016 22:20:45 +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 96Zmd_mkqREA for <tor-talk@lists.torproject.org>;
 Sat, 16 Jan 2016 22:20:44 +0000 (UTC)
Received: from mx1.riseup.net (mx1.riseup.net [198.252.153.129])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (not verified))
 by eugeni.torproject.org (Postfix) with ESMTPS id CA71D21BD1
 for <tor-talk@lists.torproject.org>; Sat, 16 Jan 2016 22:20:44 +0000 (UTC)
Received: from cotinga.riseup.net (unknown [10.0.1.164])
 (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
 (Client CN "*.riseup.net",
 Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK))
 by mx1.riseup.net (Postfix) with ESMTPS id AA33B1A147E
 for <tor-talk@lists.torproject.org>; Sat, 16 Jan 2016 22:20:41 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=riseup.net; s=squak;
 t=1452982841; bh=Vd0sI2Ey86Dv598+vmm11nGZf8oSf8P9W56m36xaGg0=;
 h=Subject:To:References:From:Date:In-Reply-To:From;
 b=F6jqHeNW+P8Ex48cX/YXSRQnKQzxRtQS5wBLm1bKmc0OsyGTsITQ4ZQdjU9TO9XmB
 22fiv3DRe8ccW+kvkvsAmOPxnZm+P4p7M1Em5ds1Zh5XsUOwre/kuJxwsI72FV6QYY
 FfLA7TKCPHe2YIXhNFMyZFb73tQfN/g1TRKvYc0A=
Received: from [127.0.0.1] (localhost [127.0.0.1])
 (Authenticated sender: mirimir) with ESMTPSA id 09DB4403B2
To: tor-talk@lists.torproject.org
References: <20160116212250.GA14827@ix-293.local>
From: Mirimir <mirimir@riseup.net>
X-Enigmail-Draft-Status: N1110
Message-ID: <569AC237.7040406@riseup.net>
Date: Sat, 16 Jan 2016 15:20:39 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <20160116212250.GA14827@ix-293.local>
X-Virus-Scanned: clamav-milter 0.98.7 at mx1.riseup.net
X-Virus-Status: Clean
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: 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>

On 01/16/2016 02:22 PM, Rejo Zenger wrote:

> Hi!
> 
> I'm wondering... 
> 
>  - 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...

<SNIP>

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

I GnuPG sign pages on http://dbshmc5frbchaum2.onion and have the public
key online in four other independent places. I recommend that users
first verify that all five places provide the same public key. Then they
can verify that the signatures are valid.

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

Well, the key should be backed up, so we can ignore this issue.

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

If the key has been stolen, an adversary could use it to spoof the site.
If both the real site and spoofed site are up, users will generally
reach the one where the tor process has restarted most recently. And if
the site owner generates a new hostname, the real site looks like a spoof.

But GnuPG signing resolves the issue. The private GnuPG key never leaves
the operator's machine. For best security, the private GnuPG key never
leaves an air-gapped machine.

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


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

