[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: When should we https our mirrors?



On Mon, Oct 24, 2016 at 07:26:37PM +0200, Tollef Fog Heen wrote:
> ]] Paul Tagliamonte 
> > On Mon, Oct 24, 2016 at 04:00:39PM +0100, Ian Jackson wrote:
> > > It is also evident that there are some challenges for deploying TLS on
> > > a mirror network and/or CDN.  I don't think anyone is suggesting
> > > tearing down our existing mirror network.
> > 
> > https://deb.debian.org/ is now set up (thanks, folks!), so my attention
> > is now shifted away from the push to https all the things (not everyone
> > will, so I just want a stable well-used domain that could be a sensable
> > default, and let those who don't want to move forward stay in the past)
> > and on to considering the apt https transport and thoughts on how this
> > could become part of the base install.
> 
> Note that the performance of HTTPS there is worse than for HTTP due to a
> lack of SRV support in apt-transport-https, though, which means it falls
> back to doing HTTP redirects.

(as apt-transport-https is mentioned I have to comment again…)

It should be only one redirect with apt >= stretch for indexes. For the
*.debs its a redirect each. APT doesn't store redirects between runs as
its hard to keep that current and authoritative (obvious for http,
slightly less obvious for https perhaps).

The SRV support needs to be implemented in (lib)curl as I wouldn't feel
to comfortable working around this [0]. Or, well, implement TLS in apt
directly, but I already mentioned how likely I think that is, but if
anyone wants to try…

And as already mentioned pipeline support in a-t-https would be nice if
someone feels like implementing it via curls multi-interface.

If someone is exceptionally bored we could implement an opportunistic use
of https if a-t-https is installed and "_https._tcp." srv-lookups get
a favorable response by letting http ask for that first and internally
redirect in that case.

So, you see, as usually, there isn't a shortage on ideas. If someone
wants to work on any feel free to join deity@ and/or #debian-apt.


Best regards

David Kalnischkies

[0] which isn't exactly easy and could only be considered a hack as you
can't take over resolving for curl, you could just misuse a facility for
DNS caching to feed it an IP, but you first need to establish that this
IP and port can be connected to, disconnect and hope a "reconnect" in
curl will be equally successful later on as making sense of error codes
isn't exactly easy either…

Attachment: signature.asc
Description: PGP signature


Reply to: