Foiling MITM attacks on source and ports trees

[cpghost]

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 <vince at 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/