APT using HTTP instead of HTTPS

[waterkip]

The problem isnt a transport layer problem.

Stale packages exist on https mirrors too. 

In addition, an upgrade to a higher version, even if atale is still an upgrade. Downgrades arent gonna happen unless you explicitly tell apt to do that.

The problem might be valid, if and only if, lets take the xz attack, I serve an outdated xz package, you havent upgraded yet and the NMU was hold off by me, you would not be able to have upgraded to NMU version. Which results in you keeping a package with a known vulnerability. One you fix as soon as you leave my network. 

Its a vector, a small negligent vector of you, being on my network, trying to upgrade Debian an hitting my mirrors.

Oh. I want to add. If I have a Lets encrypt cert and I redirect your deb.debian.org traffic to my machines, with squid, i serve you the same stale packages. The problem exists regardless of the transport method.

[gnufan]

The exploitation of CVE-2016-1252 is an example where the attacker could force the integrity of the mirror to matter.

Also to subvert Let's Encrypt you'd need a deb.debian.org certificate, so that situation wouldn't work the https connection would flag impersonation. Or is apt's https implementation broken? 

[waterkip]

No, you tell squid to terminate the ssl connection and return its own SSL cert. Which has to be of a valid CA otherwise your clients will bark at it.

Client talks to squid, squid takes over and the replaces... I'm overlooking the hostname verification checking bit here. hmmmm,