Date: Fri, 18 Jan 2013 03:57:21 +0100 From: Michael Gmelin <freebsd@grem.de> To: freebsd-ports@freebsd.org Subject: Using bidirectional authentication in pkgng Message-ID: <20130118035721.283135fb@bsd64.grem.de>
next in thread | raw e-mail | index | archive | help
Hi, I'm currently assessing migrating our internal package distribution infrastructure to pkgng. We run a couple of build hosts that create a mix of ports based packages and packages created through our own proprietary build system. Assuming we changed all of this to use pkgng, we would face the problem of how to distribute packages in a way that meets the following requirements: 1. The packages shouldn't be tampered with - in addition to signing the repo using an RSA key (if that's sufficient anyway) it would be best to have some server authentication/trust 2. The packages shouldn't be requested by an unauthorized host Some packages contain licensed software that should not be installed on unauthorized hosts. Therefore clients should authenticate themselves. Obviously encryption on transport has to be utilized as well. My preferred setup would be using sftp with public authentication, since this is the kind of inter-server trust structure we're using already anyway. Repo side we would create one user per package-set, allowing chrooted sftp access (internal-sftp, extremely fast to set up), adding the public keys of all servers with access to a specific package set to ~/.ssh/authorized_keys. Client side we would accept the repo server's public key, add a few lines to /root/.ssh/config and set PACKAGESITE to something like "sftp://myserversip/pkg". A setup that would probably take less than 10 minutes to accomplish. Unfortunately right now sftp is not an option in pkgng, fetch operations are done using libfetch. So the alternative would be using HTTPS with client certificates. Unfortunately those are not supported either, so we would have to fallback to using http auth (e.g. environment variable HTTP_AUTH) with HTTPS. This would work, but libfetch does not support any form of server certificate verification/validation (check CN, verify it's a trusted CA etc.) - which means that the solution would be open to man-in-the-middle attacks. Assuming the RSA signing mechanism of the repo is reliable this means that requirement 1 would still be fulfilled, but requirement 2 wouldn't, since intercepting the credentials would be fairly easy to accomplish in this scenario. So.. what to make of this? a. I understand that my use case is not necessarily pkgng's top priority. Ultimately requirement 2 is pretty nonsensical for distributing open source packages b. It still would be great if sftp could somehow be supported in the future - or at least some syntax that allows external tools to be called to accomplish the task. That way people could use sftp, curl or what not to fetch packages. c. libfetch really needs to get fixed to allow certificate verification in its fetchX* and fetchHTTP* functions when using HTTPS. fetch(3) is based on it and there is no indication anywhere whatsoever that no checks are done at all (none of the libfetch or fetch utility man pages mention it). Afaik base doesn't contain sufficient CA information, so it probably would have to rely on a port. What I could imagine is enabling such a check by default and allow disabling it through command line parameter / environment variable / config file, giving some helpful error message on check failure like: "You might want to install security/ca_root_nss". That way ports and other automated tools could leave it turned off by default, but users who use the utility on the command line (or tools using libfetch) get actually some basic protection. Client certificate support would be nice as well, but.. you know. Cheers, Michael -- Michael Gmelin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130118035721.283135fb>