Re: When should we https our mirrors?
Tollef Fog Heen wrote:
> ]] Paul Tagliamonte
>
> > So, when are we going to push this? If not now, what criteria need to
> > be met? Why can't we https-ify the default CDN mirror today?
>
> The usual crypto answer: because key handling is hard.
>
> Doing this for the per-country mirrors means that repointing mirrors
> becomes a lot harder than it currently is, and this is something we do
> on a daily basis. We'd need a solution for deploying the TLS cert for,
> say, ftp.de.d.o to ftp.se.d.o (or ftp.d.o) if ftp.d.o is down for
> maintenance.
>
> Doing this for deb.d.o would mean we need to get certs on both Fastly
> and Cloudfront deployed, which is, frankly, a more realistic proposition
> than jury-rigging something on the per-country mirrors.
Hi,
Since the Debian project controls the mirror client (in particular the
code responsible for performing certificate validation), surely there is
some way we can engineer our way to a less painful solution? We don't
have to imitate the way web browsers or other HTTP clients perform
certificate validation, right?
We currently use DNS SRV records for a few mirror domains to direct apt
traffic, e.g. for ftp.us.debian.org:
;; QUESTION SECTION:
;_http._tcp.ftp.us.debian.org. IN SRV
;; ANSWER SECTION:
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 ftp-chi.osuosl.org.
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 2 80 ftp-nyc.osuosl.org.
_http._tcp.ftp.us.debian.org. 3600 IN SRV 0 1 80 debian.gtisc.gatech.edu.
If there were some way to be able to trust the SRV target names (the
right-most names in the above output like "debian.gtisc.gatech.edu",
which tend to be very stable since they're chosen by the mirror
operator), we could use those names as the domain name in the TLS
certificate to be validated by apt, and it would be easy for a mirror
operator to go off and acquire a TLS certificate for the "canonical"
name of their server, rather than the .debian.org alias. Unfortunately,
the data in the SRV records comes from the DNS, and even though the
debian.org zone is signed, we cannot currently rely on DNSSEC validation
occurring (and occurring successfully) on every Debian system running
apt.
Some possibilities:
1)
Maybe we could securely distribute the list of canonical mirror names
via security.debian.org (using traditional certificate validation
rules), either in a package or in metadata stored in the archive?
2)
Maybe we could constrain apt so that it would use the (untrusted) DNS
SRV target names for certificate validation only if the names were
rooted in a base domain name on a whitelist? E.g., if the SRV target
name ends in "._tls-servers.debian.org", then that name can be used as
the name to be validated in the TLS certificate. Then we could set up
SRV RRs that use aliased mirror hostnames like this:
_https._tcp.ftp.us.debian.org. SRV 0 1 443 ftp-chi.osuosl.org._tls-servers.debian.org.
_https._tcp.ftp.us.debian.org. SRV 0 2 443 ftp-nyc.osuosl.org._tls-servers.debian.org.
_https._tcp.ftp.us.debian.org. SRV 0 1 443 debian.gtisc.gatech.edu._tls-servers.debian.org.
and then alias those target names to the canonical mirror hostnames:
ftp-chi.osuosl.org._tls-servers.debian.org. CNAME ftp-chi.osuosl.org.
ftp-nyc.osuosl.org._tls-servers.debian.org. CNAME ftp-nyc.osuosl.org.
debian.gtisc.gatech.edu._tls-servers.debian.org. CNAME debian.gtisc.gatech.edu.
Then the operator of debian.gtisc.gatech.edu only has to go off and set
up a vhost for "debian.gtisc.gatech.edu._tls-servers.debian.org" in the
mirror server's HTTP config, and acquire a TLS certificate for that
name.
Both of these options have the problem that a potential MITM can just
become a rogue mirror operator, but perhaps more fine-grained
constraints could be defined, or we could require the same level of
trust for HTTPS mirror operators that we do for new maintainers (i.e.,
PGP signatures from two active developers)?
--
Robert Edmonds
edmonds@debian.org
Reply to: