Date: Sat, 03 Jan 2009 12:45:11 +0000 From: Matthew Seaman <m.seaman@infracaninophile.co.uk> To: RW <rwmaillists@googlemail.com> Cc: freebsd-questions@freebsd.org Subject: Re: Foiling MITM attacks on source and ports trees Message-ID: <495F5DD7.2070302@infracaninophile.co.uk> In-Reply-To: <20090103013825.18910bf5@gumby.homeunix.com> References: <20090102164412.GA1258@phenom.cordula.ws> <495E4F24.80209@unsane.co.uk> <20090103013825.18910bf5@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig193E7ECC23B5DC2F05D6A9E6
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable
RW wrote:
> On Fri, 02 Jan 2009 17:30:12 +0000
> Vincent Hoffman <vince@unsane.co.uk> wrote:
>> Admittedly this doesn't give a file by file checksum
>=20
> That's not really a problem, it's no easier to create a collision
> in a .gz file than a patch file.=20
>=20
> 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 roun=
d
this problem is to cryptographically sign the (lists of) checksums using
some form of public/private key pair.
Unless designed carefully, there will be substantial logistical problems =
to
maintaining such lists of signatures. The least laborious mechanism I ca=
n
think of would be this: an SSL secured web site using a key+cert signed b=
y
a trusted CA[*]. This site would have privileged access to the master re=
positories
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 whateve=
r
else is necessary to uniquely identify the specific file in question woul=
d
be answered with a list of checksums (MD5, SHA1, SHA265 etc.) of that fil=
e.
Obviously, this will require substantial caching of previously calculated=
checksums simply for performance. =20
As an end user, you check out sources etc. from whatever of the mirrors i=
s
most suitable. You can then verify the correctness of what's on your dis=
k
by comparing a locally generated checksum with what you can download via =
a
trusted channel from the checksum server. Since the checksum server is o=
nly
accessible via HTTPS and has a trusted certificate it should not be possi=
ble
to spoof. Traffic levels should be relatively small compared to the main=
distribution channels. Even so, because of the SSL requirement it's goin=
g to
take a substantial piece of kit to provide this checksumming service at a=
decent performance level, especially when there are recent new releases.=
Cheers,
Matthew
[*] Buying a high security cert from the likes of Verisign or OpenSRS wou=
ld
set you back about =A3800 p.a. and it would probably be necessary to use =
someone
like the FreeBSD Foundation as an appropriate body to own the cert.
--=20
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
Kent, CT11 9PW
--------------enig193E7ECC23B5DC2F05D6A9E6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEAREIAAYFAklfXd0ACgkQ8Mjk52CukIy1WgCfVO/dE3KyvDF/j6eAc3rjcNDv
qpsAnRtUQzEss/man+vjdvMgWYfY8Icv
=MoOL
-----END PGP SIGNATURE-----
--------------enig193E7ECC23B5DC2F05D6A9E6--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?495F5DD7.2070302>