Hi, On 04.09.21 22:12, Hideki Yamane wrote:
The TLS layer is not part of the security model, so we'd be teaching users to look for the wrong thing, kind of like the "encrypted with SSL" badges on web pages in the 90ies.
Is there any strong reason to use HTTP than HTTPS now?
The strongest reason (IMO) in favor of unencrypted transmission is that it doesn't introduce a policy decision. The package "ca-certificates" must be installed and a checkmark set for the "mozilla/ISRG_Root_X1.crt" certificate, otherwise updates will break.
If we want to have HTTPS as default, we need additional logic to make sure certificates are installed and cannot be deinstalled (so Essential or a strong dependency chain from an Essential package) and that the certificate cannot be deactivated, or apt needs its own repository of trusted certificates.
With the current Docker images: $ docker run --rm -it debian:bullseye root@32529bf86cd3:/# sed -i -e s/http/https/ /etc/apt/sources.list root@32529bf86cd3:/# apt update Err:1 https://deb.debian.org/debian bullseye InReleaseCertificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443] Err:2 https://security.debian.org/debian-security bullseye-security InRelease Certificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 151.101.66.132 443]
Err:3 https://deb.debian.org/debian bullseye-updates InReleaseCertificate verification failed: The certificate is NOT trusted. The certificate issuer is unknown. Could not handshake: Error in the certificate verification. [IP: 199.232.138.132 443]
So changing the default is not sufficient here, we'd need a lot of additional work and testing to ensure this works for everyone, not just the desktop users.
Another important argument is that it creates a dependency on third-party commercial CDNs, and their *continued* sponsorship.
Debian is very conservative when spending money and generally shies away from recurring expenses because we do not want to find us in a situation where we are dependent on an external entity making a timely donation in order to keep operations running, so I wonder why we are that accepting of it in one of our core services, and I certainly don't think we should be adding additional roadblocks should we ever need to find an alternative.
We have a (crude) load-balancing framework in infrastructure we control that can point requests towards a set of untrusted mirrors, and while it's nice that we don't *need* to use this fallback plan, it is reassuring it is there.
Should we teach all our users (including non-tech) about "Secure APT" mechanism?
If they ask why we're not using HTTPS, yes: it helps clear up the misconception that anything with an "s" in it is secure and can be trusted.
Anyone who configures an additional source needs to know how the authentication mechanism works anyway, so we're not gaining anything there either.
Simon
OpenPGP_signature
Description: OpenPGP digital signature
