Re: HTTPS metadata in Mirrors.masterlist?
On Sat, 15 Feb 2014, Joerg Jaspert wrote:
> The biggest problem I see is with what Kurt posted:
>
> > So the first question I have about this if we can get
> > ftp.TLD.debian.org certificates for this, and what happens when
> > that host is down and DNS gets pointed to a different host?
>
> > I have to guess that we should only do that on the hostname that
> > is not ftp.TLD.debian.org, while I think it now only shows that
> > name?
>
> I see no real problem in getting certificates for those domains - way
> more interesting is the handling of them. ftp.*.d.o gets pointed around
> to other mirrors when the usual "owner" of it is down for whatever
> reason. Depending on the country it may also end up on mirrors really
> far away (better that than no ftp.whatever.d.o). So some mirror
> somewhere may not just need one of those certs, but multiple[1]. And a
> single cert/key must be on loads of mirrors. And then comes handling of
> renewals too.
>
> So only using it on the mirrors actual hostname would be sensible.
Well, the user requested that we add https support to the tools (so that
individual mirrors and private mirrors can go https if they want), not to
the mirror network itself.
Also, IMHO if one is going to add SSL/TLS support to the tools, it needs to
be done properly. I.e. certificate path validation is a must (e.g.
validating the chain to a manually trusted certificate, or to a trusted CA
root), and DANE support would be nice (which is kinda hard, as DANE done
properly requires a validating DNSSEC resolver). Non-validated SSL/TLS
connections are trivial to MITM and usually it is just a waste of resources.
So, enabling it on the mirror network is, as you wrote, also a PKI problem
due to our use of dynamic aliases.
However, IMHO we don't need to support SSL/TLS pervasively on the mirror
network. It gives us very little as far as security and privacy are
concerned, for a real and non-trivial cost on resources and PKI operational
concerns. Traffic analyisis makes it trivial to disclose what packages are
being downloaded and we already do MUCH stronger package content validation.
In this specific case, SSL/TLS support is only useful on limited situations
(and I assume the user that requested https support needs it for one of
those limited situations -- e.g. his adversary is incapable of proper
traffic analysis, or he just needs to avoid content inspection).
So, for the mirror network, IMHO it would be enough to deploy TLS
certificates for select mirrors using only the specific mirror host names,
leaving the aliases such as ftp.*.d.o out of it. Let's not waste resources
and create operational problems where not required: the people who really
need https can use specific mirror host names instead of aliases (or will be
using private mirrors anyway).
> [1] Unless we really can do a wildcard of ftp.*.debian.org, which I dont
> know, but which would allow mirror admins to use it for
> ftp.anything.debian.org too. Huh.
This is likely to be far more trouble than it is worth, IMHO.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: