Hi,
- when you use switches, the local network segment has no other nodes - if there were other nodes, they would likely miss some packets in the conversation, which means they cannot generate checksums - there is no software that can perform this inspection
Yep, there are limitations to work within, and the result would be the groundwork for some kind of 'integrity appliance', either within the local network or deliberately outside of it.
There are commercial security solutions that aim to implement this, and many of these also contain solutions to inspect the contents of TLS traffic, usually by creating their own CA and requiring clients to install their certificate as trusted.
These are then rolled out on the edge of company networks. As you can imagine, that comes with its own set of downsides, and I'd argue it makes things a lot less secure, especially if you treat it as a product that can be installed once and then forgotten about.
For the specific case of package downloads, I'd also argue that it is unnecessary, because apt already verifies integrity on the client, and such an appliance would have no additional information to act on that the client does not have.
An alternative (that may already exist, I would be surprised if not) would be to run two-or-more instances of the same computing hardware with key I/O interfaces between all of them.
This is being done already, but systems like these are generally not connected to the Internet.
I think it's fine if we're making a change that is broadly agreed upon; I wasn't able to find a decision that would be suitable to link to from the documentation (or commit log) when searching the mailing lists earlier, and since it's debatably-meritable change with potential impact on users and infrastructure (albeit in a gradual way) I wanted to raise some awareness and also check where the reasoning for the change originates.
I'd also have to search the archives, but I remember the last discussion as I was part of it.
The reason for the change is that it reduces user confusion. Users are learning that unencrypted HTTP has neither integrity nor confidentiality, and that they should actively check that web sites use HTTPS, so we have gotten several inquiries why apt uses an "insecure" protocol.
It takes time to explain that apt performs its own integrity checks, and we can not and should not explain away the missing confidentiality, because we're happy that they want to protect their information and are insisting on using TLS -- that is far from perfect, but already a vast improvement.
Infrastructure-wise, Docker is the far bigger problem, because people keep downloading the same packages over and over again, and the traditional mirror network donated by universities already had trouble keeping up. Two large CDNs are also donating mirrors now, and we use these preferentially.
The CDN mirrors also come with caching infrastructure and can terminate TLS, which the traditional network cannot because there is no key/certificate distribution infrastructure (and such a thing can only exist within a single organization), so the last strong technical reason for not using HTTPS went away.
The remaining technical reasons are weak, so a non-technical reason prompted the change in default.
Simon