[Dormeno]

One important factor this article left out is upgrades. If the given HTTPS implementation is broken because of what is now insecure protocols, insecure ciphers etc. Older systems can't update from the mirror if it's updated to use a 'secure' HTTPS configuration while it only supports the 'vulnerable' solution. If HTTPS is left insecure, then it is not much different from using HTTP.

APT's methodology avoids this and as the current signing and protection mechanisms are file based, the worst case scenario is introducing a new file with a new cryptographic signature along side the old schema, to support still updating a system running old security mechanism.

In comparison, trying to run multiple HTTPS servers with different configurations for specific versions of the system being updated would be a significant engineering effort, especially for mirrors.

[da_chicken]

Huh? All you would do is configure the web server running your apt mirror site to serve the same content on both HTTP and HTTPS ports. If the client want to use TLS, they connect to HTTPS. If they want to use plain HTTP, they connect to HTTP. Both sites serve the same content, which is just a series of flat files. AFAIK, the client is responsible for determining the correct versions for the installed distro based on the indices.

This is what many mirrors already do:

http://mirrors.lug.mtu.edu/debian/

https://mirrors.lug.mtu.edu/debian/

[toast0]

If your installed version is configured for https, but is incapable of using TLS 1.2, because it's rather old, at some point soon, a modern mirror would no longer allow it to connect as 2019 (or maybe 2020) seems to be shaping up as the year to kill support for TLS 1.0 and 1.1. Meanwhile, an http config would continue to work.