Delivery-Date: Tue, 03 Feb 2015 23:02:53 -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.8 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_MED,
	RP_MATCHES_RCVD,URIBL_BLOCKED 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 939DA1E0BB2
	for <archiver@seul.org>; Tue,  3 Feb 2015 23:02:51 -0500 (EST)
Received: from eugeni.torproject.org (localhost [127.0.0.1])
	by eugeni.torproject.org (Postfix) with ESMTP id A1AC233677;
	Wed,  4 Feb 2015 04:02:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by eugeni.torproject.org (Postfix) with ESMTP id 2E05733638
 for <tor-talk@lists.torproject.org>; Wed,  4 Feb 2015 04:02:44 +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 0GFJuLN4ZFpG for <tor-talk@lists.torproject.org>;
 Wed,  4 Feb 2015 04:02:44 +0000 (UTC)
Received: from roffey.org (roffey.org [5.9.178.151])
 by eugeni.torproject.org (Postfix) with ESMTP id 006893363B
 for <tor-talk@lists.torproject.org>; Wed,  4 Feb 2015 04:02:43 +0000 (UTC)
Message-ID: <54D199A0.2000502@roffey.org>
Date: Wed, 04 Feb 2015 04:01:36 +0000
From: Andrew Roffey <andrew@roffey.org>
MIME-Version: 1.0
To: tor-talk@lists.torproject.org
References: <CALoT2zaPdX6+eEwEF=S94_E8nEBVzyF8jkatGTiJQZ3rPyJz9Q@mail.gmail.com>
 <54D181A0.4030908@roffey.org> <20150204022524.GI26784@mail2.eff.org>
In-Reply-To: <20150204022524.GI26784@mail2.eff.org>
Subject: Re: [tor-talk] "Confidant Mail"
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>

>> Then GnuPG signatures would perhaps be more appropriate in this 
>> instance?
> 
> The Tor Project itself has found that users often don't verify GPG 
> signatures on binaries (I think Mike Perry quoted some statistics 
> about how often the Tor Browser binary had been downloaded in 
> comparison to the .asc signature file -- it was orders of magnitude 
> less often).  That suggests to me that HTTPS should be used for 
> software distribution authenticity even when there's a signature 
> available; the importance of this only diminishes if the signature 
> will be verified automatically before installation (like in some 
> package managers).  That's usually not the case for first-time 
> installations of software downloaded from the web.
> 
> (I don't think the Tor Project has studied _why_ the users didn't 
> verify the signatures -- there are tons of possible reasons.  But 
> it's clear that most didn't, because the .asc file is so rarely 
> downloaded.)


This isn't intended to answer the question, but I've noticed the
signature isn't shown very prominently on the download page, at least
compared to other websites such as the Apache Tomcat page:

> Release Integrity
> 
> You must verify the integrity of the downloaded files. We provide 
> OpenPGP signatures for every release file. This signature should be 
> matched against the KEYS file which contains the OpenPGP keys of 
> Tomcat's Release Managers. We also provide MD5 and SHA-1 checksums 
> for every release file. After you download the file, you should 
> calculate a checksum for your download, and make sure it is the same
>  as ours.

(from: https://tomcat.apache.org/download-80.cgi)


HTTPS is, in theory, a good idea on downloads considering a lot of users
won't bother with signatures (although GnuPG signatures are
nice as well).

The main problems with HTTPS (from a hosting perspective) are that:

 - it is much more resource intensive than plain HTTP (especially on
   servers hosting large files);
 - it more or less rules out using third-party mirrors unless you can
   trust them because integrity is provided per-connection rather than
   per-file; and
 - there is a cost of obtaining HTTPS signatures.

Also consider the security of the CA model and the probable likelihood
that at least one of the hundreds of the authorities has been
compromised and could be used to issue fraudulent certificates to MITM
high value targets.

tl;dr: anyone with enough time, money and resources should definitely
consider deploying HTTPS, preferably alongside GnuPG signatures for the
paranoid.

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

