On Sunday, October 16, 2016, Tollef Fog Heen <tfh...@err.no> 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
I agree key handling is difficult, but it's not that hard to work
around such scenarios when HTTP 302 can be provided from the original
maintianers (i.e. through a temporary virtual machine).
Actually we have backup plan on ftp.cn.d.o and ftp2.cn.d.o
that is battle-tested. They would redirect traffic to selected mirrors in a
way similar to httpredir.d.o when outages happen. Performance and bandwidth
requirements are acceptable for a temporary service even they are of the
busiest FOSS mirrors in China.
The two mirrors are delivering most of the traffic through HTTPS
nowadays according to statistics because we've deployed User-Agent based
HTTPS redirection on all supported domains and never heard a complain.
Overhead is negligible because IOPS of disk arrays is always the most
significant problem and bandwidth the next.
> 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.
There's no reason to not do it, but it doesn't cover parts in the world
like China where neither Fastly nor Cloudfront provides a decent service.