Hello, with MITM attacks  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.
 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. 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: 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. -- Cordula's Web. http://www.cordula.ws/ _______________________________________________ firstname.lastname@example.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"