Hi,
On 5/31/23 05:42, James Addison wrote:
* It allows other devices on the local network segment to inspect the
content that other nodes are sending and receiving.
That is very theoretical:
- 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
A place where such an inspection would be possible is a local proxy, but
this is also not being done because even a caching proxy wants to
forward data as it arrives, and there is no gain in security as the
proxy can only use the same verification method as the client.
* As another thread participant mentioned, if you don't trust a global
passive adversary, then it may be sensible to question whether you can
trust their certificate issuers (I admit that your HPKP comments partially
address this concern). If you don't trust either, you might choose to save
some CPU cycles (both for yourself and those who may be gathering your
data).
The reason we're even having this debate is that the use of TLS is of
little consequence from an integrity point of view, because we're doing
our own verification with our own PKI that is independent from TLS
certificate issuers, and that isn't going to change.
Because the use of TLS is inconsequential, it is a trade-off between
various weak reasons:
1. unencrypted HTTP can be cached with a caching proxy
2. unencrypted HTTP can be redirected to a local mirror
3. encrypted HTTPS does not let a listener determine quite as easily
what software you are running on your machine
4. encrypted HTTPS requires CA certificates to be deployed to clients
and marked as trusted, or apt will fail.
Whether a caching proxy and/or redirection to an unofficial nearest
mirror are desirable or undesirable also depends on your stance -- my
Docker machines download the same packages sometimes thirty times a day,
so being able to redirect deb.debian.org to a local mirror is a massive
performance boost, but also means sometimes images are built with stale
packages.
To everyday users in developed countries, this change is completely
irrelevant: they get a default configuration with all CAs trusted either
way, they get packages from a content delivery network that has HTTPS
acceleration so that is not a bottleneck, and modern CPUs have
cryptographic primitives so this uses less CPU time than decompression.
I've raised all of these points in a previous debate already, so I
believe they have been taken into account in the current decision. No
users in developing countries have chimed in, so it does not seem to be
a priority there either, and the Docker users can help themselves with a
sed invocation as part of the image build.
So far, I'm not seeing a reason to restart this debate; for that to
happen, we'd need to find at least someone for whom that change is more
than a slight inconvenience.
Simon
