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 edmo...@debian.org
