From owner-freebsd-questions@FreeBSD.ORG Fri Jan 2 17:30:31 2009 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AAFB6106566C for ; Fri, 2 Jan 2009 17:30:31 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from unsane.co.uk (unsane-pt.tunnel.tserv5.lon1.ipv6.he.net [IPv6:2001:470:1f08:110::2]) by mx1.freebsd.org (Postfix) with ESMTP id 19A228FC12 for ; Fri, 2 Jan 2009 17:30:30 +0000 (UTC) (envelope-from vince@unsane.co.uk) Received: from vhoffman.lon.namesco.net (150.117-84-212.staticip.namesco.net [212.84.117.150]) (authenticated bits=0) by unsane.co.uk (8.14.0/8.14.0) with ESMTP id n02HUps2097533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jan 2009 17:30:52 GMT (envelope-from vince@unsane.co.uk) Message-ID: <495E4F24.80209@unsane.co.uk> Date: Fri, 02 Jan 2009 17:30:12 +0000 From: Vincent Hoffman User-Agent: Thunderbird 2.0.0.19 (Macintosh/20081209) MIME-Version: 1.0 To: cpghost References: <20090102164412.GA1258@phenom.cordula.ws> In-Reply-To: <20090102164412.GA1258@phenom.cordula.ws> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-questions@freebsd.org Subject: Re: Foiling MITM attacks on source and ports trees X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jan 2009 17:30:31 -0000 cpghost wrote: > Hello, > > with MITM attacks [1] on the rise, I'm concerned about the integrity > of local /usr/src, /usr/doc, and /usr/ports trees fetched through csup > (and portsnap) from master or mirror servers. > > [1] http://en.wikipedia.org/wiki/Man-in-the-middle_attack > > There's already a small protection against MITM on the distfiles in > ports: distinfo contain md5 and sha256 digests. This is an excellent > idea that could be extended to *all* files in /usr/src, /usr/doc, and > /usr/ports. > According to http://www.daemonology.net (the creator of portsnap and also freebsd-update as well as being the freebsd security officer's website) and a quick look though the freebsd-update and portsnap scripts, both portsnap and freebsd update provide reasonable cryptographic protection from MITHM attacks. ({freebsd-update,portsnap}.conf contains a sha256 hash of the rsa key used to sign the updates) Admittedly this doesn't give a file by file checksum but does give reasonable protection against MITM attacks for updates of the ports tree and the -RELEASE src trees. Vince > What I'd like to have is a way to check the fetched /usr/src, > /usr/doc, and /usr/ports files against a *digitally signed* list of > (file, revision, digest) tuples that would be generated on-the-fly and > on-demand, so that any modification of the files in transit would be > detected (provided the checker program runs on an uncompromised host, > of course). > > This should not only apply to up-to-the-minute current files, but also > to files fetched, say, a few weeks or months ago (e.g. because they > are deployed in stable production servers). > > Assuming there's a secure way (which is not affected by MITM) to > obtain a master public key (GnuPG key) of the FreeBSD Project, it > would be nice to have a mechanism in place that would: > Agreed, a more secure way of getting it than http://www.freebsd.org/security/so_public_key.asc would be nice, (just ssl would make me happy.) > 1. create a compressed list of (file, revision, md5/sha1/...digest) > tuples for /usr/src, /usr/doc, and /usr/ports trees, > > 2. sign this list with the master private key of the project and > make it available. > > Because the number of revisions for any specific file can be huge, > this list could grow very fast. It may be economical to have the > program create only (file, revision, digest) tuples for a limited > number of revisions, typically as many as needed between start and end > of a typical csup run on slow links, or at most, say, 24h... starting > at an arbitrary date in the past. > > To save CPU cycles, previous computed (file, revision, digest) > tuples could be permanently cached in an RDBMS, in Subversion or > wherever else that's appropriate. > > Oh, we could always use SSL between csup and the servers as fallback, > but SSL is not without flaws and I doubt that all mirrors would have > valid certificates, defeating the whole purpose of foiling MITM > attacks. And SSL alone doesn't permit checking "after the fact" > the integrity of an older snapshot. > > Any idea? Could this be implemented as a plugin to Subversion (since > it must access previous revisions of files and previously computed > digests)? Given read-only access to the repository, a set of simple > Python scripts or C/C++ programs could easily implement the basic > functionality and cache the results for fast retrieval by other > scripts. But how well will all this scale? > > Thanks, > -cpghost. > >