On Sat, Jan 03, 2009 at 12:45:11PM +0000, Matthew Seaman wrote: > RW wrote: > > On Fri, 02 Jan 2009 17:30:12 +0000 > > Vincent Hoffman <vi...@unsane.co.uk> wrote: > >> Admittedly this doesn't give a file by file checksum > > > > That's not really a problem, it's no easier to create a collision > > in a .gz file than a patch file. > > > > The more substantial weakness is that the key is verified against a > > hash stored on the original installation media. If someone went to the > > trouble of diverting dns or routing to create a fake FreeBSD site they > > would presumably make it self-consistent down to the ISO checksums. > > Yes. Anyone can generate checksums. The standard method of getting round > this problem is to cryptographically sign the (lists of) checksums using > some form of public/private key pair.
Right. > Unless designed carefully, there will be substantial logistical > problems to maintaining such lists of signatures. The least > laborious mechanism I can think of would be this: an SSL secured web > site using a key+cert signed by a trusted CA[*]. This site would > have privileged access to the master repositories and would run a > fairly simple CGI where supplying the location of a file from a > checked out copy of a repo, plus version number information and > whatever else is necessary to uniquely identify the specific file in > question would be answered with a list of checksums (MD5, SHA1, > SHA265 etc.) of that file. Actually, one only needs SSL to access a site that distributes the public key used for signing the lists of checksums. If this key is widely distributed, we could even do without an SSL certificate (though having one would be good, if the FreeBSD Foundation could pay for one). > Obviously, this will require substantial caching of previously > calculated checksums simply for performance. Already suggested. ;) > As an end user, you check out sources etc. from whatever of the > mirrors is most suitable. You can then verify the correctness of > what's on your disk by comparing a locally generated checksum with > what you can download via a trusted channel from the checksum > server. Since the checksum server is only accessible via HTTPS and > has a trusted certificate it should not be possible to spoof. Exactly. That's the basic idea. But even if we didn't have a trusted connection to the checksum server, the lists of checkums could still be digitally signed, and everyone who obtained the widely-known public key through a non-MITMed channel could still verify the integrity of this list. The idea is that one needs to get this public key only once from a secure channel, and could use it forever (or as long as it is valid and not revoked) to verify the signature of the checksum lists (which could themselves be distributed via non-trusted channels. > Traffic levels should be relatively small compared to the main > distribution channels. Even so, because of the SSL requirement it's > going to take a substantial piece of kit to provide this > checksumming service at a decent performance level, especially when > there are recent new releases. IMHO, this could or should take place at the subversion server itself. Every commit should trigger an event, and the event handler would compute a set of checksums on-the-fly and store them in the backend. This shouldn't really be any CPU burden on the server itself (how many megabytes are committed per second? per hour? ... that need to be checksummed? Not so many I guess). The kit needed would be an extra server (the checksum queries server), that would connect to the repository -- or to the database that contains the cached checksums -- and reply to client queries such as: "Gimme a list of checksums for this-and-this-subtree starting at timestamp N and ending at timestamp N+24h" (or perhaps just: "starting at timestamp N" and defaulting to the inteval [N, N+24h] to avoid denial of service attacks by too broad interval queries) This server would then query the database or backend, and simply assemble a list of checksums, compress it, digitally sign the result with the Project's key, and send the binary stream back to the client. The client would verify the signature it got from the checksum queries server with the public key it obtained through secure channel, unpack the list, and compare the local checksums with the checksums on the list. > Cheers, > > Matthew > > [*] Buying a high security cert from the likes of Verisign or OpenSRS would > set you back about ?800 p.a. and it would probably be necessary to use someone > like the FreeBSD Foundation as an appropriate body to own the cert. -cpghost. -- Cordula's Web. http://www.cordula.ws/ _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"