From owner-freebsd-hackers@FreeBSD.ORG Sun Oct 21 17:39:38 2007 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 03DCF16A418 for ; Sun, 21 Oct 2007 17:39:38 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: from redundancy.redundancy.org (redundancy.redundancy.org [64.147.160.152]) by mx1.freebsd.org (Postfix) with SMTP id F04A713C4B3 for ; Sun, 21 Oct 2007 17:39:37 +0000 (UTC) (envelope-from lx@redundancy.redundancy.org) Received: (qmail 40528 invoked by uid 1001); 21 Oct 2007 01:39:17 -0000 Date: Sat, 20 Oct 2007 18:39:17 -0700 From: "David E. Thiel" To: freebsd-hackers@freebsd.org Message-ID: <20071021013917.GB86865@redundancy.redundancy.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-OpenPGP-Key-fingerprint: 482A 8C46 C844 7E7C 8CBC 2313 96EE BEE5 1F4B CA13 X-OpenPGP-Key-available: http://redundancy.redundancy.org/lx.gpg User-Agent: Mutt/1.5.16 (2007-06-09) Subject: packages, libfetch, and SSL X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2007 17:39:38 -0000 Hello, I've been doing some thinking about the security of the packages and ports system, and have noticed that there is something of a weak link when it comes to fetch/libfetch in general, and the way we do pkg_adds in particular. While updates to the ports tree happen in a pretty secure manner over portsnap, and distfiles are verified during the build process, packages added over pkg_add -r happen over plain FTP or HTTP without any verification, allowing packages to be swapped or corrupted by a network attacker. The lowest-impact way to fix this, I think, is to use SSL for pkg_adds. There are a couple of things that would need to change to make this happen. * Package distribution sites should use SSL over HTTP. Yes, this costs money. We can either find a way to use a free solution or get people to chip in - I'd gladly put some money up for this. * libfetch needs patched to verify SSL certificate CNs and to use SSL_CTX_set_verify on SSL contexts. It should really be considered a vulnerability that this currently doesn't happen, since SSL is meaningless without this. This is easy enough to fix (about 10 lines in libfetch/common.c), but is currently not feasible because: * CA certificates are not in the base system. CA certs are currently available in the security/ca_root_nss port. Is this suitable for importing to base? If not, why not? Now, we could take another approach of PGP-signing packages instead, but all the efforts I've seen to integrate PGP with the package management system in the past haven't gone anywhere. The changes above seem to be a bit more trivial than inventing a package-signing infrastructure and putting gpg or a BSD-licensed clone into base. Perhaps using SSL to sign packages and having a baked-in key would work as well. If we don't want to do any of this, I at least think that the current SSL support in libfetch should be removed entirely, or be accompanied by a very noisy error. Any thoughts? Cheers, David