Re: When should we https our mirrors?
On Sunday, October 16, 2016, Tollef Fog Heen <tfheen@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
maintenance.
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.
Best,
Reply to: