[tz] Data loss on FTP Server

Zefram zefram at fysh.org
Wed Nov 1 04:02:52 UTC 2017

Paul.Koning at dell.com wrote:
>As for man in the middle attacks, that's what data signatures are for.
>No worries about the protocols if the data is authenticated.

This is true as far as it goes, but one has to be careful about what's
covered by the signature.  What's covered by the present signatures
is only the content of the released file.  So you know you've got an
authentic Eggert release file, and can be confident that the code in it
won't be malicious.  But you can't so easily be sure that the authentic
file you've got is the same one that you asked for: the association
between the filename and the content is not covered.  A MitM could give
you tzcode2013e.tar.gz, with matching signature, when you were expecting
tzdb-2017c.tar.lz (different tarball layout and scope, different version).

In my downloading code I've now implemented a check that the file we got
is the one we're expecting, based entirely on the content of the file.
For tzdb-*.tar.lz this is pretty easy: extract tzdb-$version/version
and check that it contains the version number.  The existence of the
file in the tarball under this directoryful name confirms that it's a
tzdb tarball, rather than tzcode or tzdata.  The content of the version
file confirms the version number, but actually the versioned directory
name in the tar also confirms that.

For current tzcode and tzdata files one can similarly check the version
file for the version number, and check some obvious filenames to determine
which kind of tarball it is.  Older tzcode and tzdata are a bit more
difficult, with the version number not being in a separate file, but
being present in the Makefile.  But actually I'm not using those trickier
checks: for everything preceding the tzdb.tar.lz era I'm baking SHA-512
hashes into my code, indexed by filename.  That also makes a signature
check redundant for these files.  Of course, that system can't cover
new releases.

FWIW, I would not regard HTTPS in the absence of the PGP signature
files as being secure against MitM attacks for this purpose.  The key
trust management is a problem in several respects that I don't want to
digress into.  The PGP signatures, applied to the files per se and made
using a key that's used for little else, are the right tool for the job.


More information about the tz mailing list