By Hans-Christoph Steiner · December 8, 2021
Debian’s package manager apt has a time-tested method of securely providing packages from the network built on OpenPGP signatures. Even though this signing method works well for verifying the indexes and package files, there are new threats that have become relevant as man-in-the-middle attacks and data mining become ever easier. Since 2013, apt developers have supported encrypted transport methods HTTPS and Tor Onion Service. We have been recommending their use since 2013.
Most major mirrors already support HTTPS, and now https://security.debian.org has finally joined the party. That means it is possible to use HTTPS on all of the official repositories. On top of that, many Debian Developers are working on making HTTPS the default for new installs.
Now is a good time to reiterate the areas of concern:
The current apt model with HTTP covers #1 well, but only covers #2 and #3 with
a one week window (the Valid-Until header sets the expiration date on the repo
metadata). That gives attackers a short-term window where blocking and replay
attacks remain effective. The And it does not cover #4 or #5 at all.
Using HTTPS adds a weak backup security layer for #1. HTTPS makes it much more difficult for certain files from a mirror to be selectively blocked or replayed, as well as making related errors louder and earlier (e.g. #2 and #3). Tracking package downloads needs only simple passive listening with HTTP, but with HTTPS, the attacker must build full indexes of package sizes, then parse the size from TLS streams. So HTTPS helps a little with #4. Lastly, there have been bugs in apt’s GPG verification. With HTTP, any network can inject exploits into apt’s downloads. HTTPS helps with #5 by providing a backup layer of encryption, albeit weaker.
It is of course important to point out that HTTPS itself has flaws, and it is not the best option out there, especially for protecting anonymity. HTTPS is quite easy to use for apt repositories, so there is hardly any trade-off to using it. That is why it is the focus of this post. If protecting privacy is important to you, you should use the Tor Onion Service repositories, especially if #4 and #5 concern you.
The only security critique of using HTTPS for repositories that still makes
sense is that there might be vulnerabilities in the code that handles HTTPS,
since its a lot more complicated that HTTP. In apt, HTTPS requires GnuTLS,
which is currently linked in by default. In order to fully protect against
exploits related to the HTTPS code, the machine would need to use a custom build
of apt with GnuTLS support not included. It is possible to limit exposure of
the HTTPS implementation by setting Acquire::AllowTLS false. This kind of
attack seems to be theoretical as of the time of writing, whereas there are at
least 6 CVEs related to exploiting the GPG verification.
Using HTTPS makes using caching proxies much harder to setup. Caching proxies can reduce the leakage of metadata about which machine is getting which package, so using direct HTTPS connections would therefore increase the leakage of that kind of metadata.
There are some additional bits of metadata that can be protected when using HTTPS, thereby further improving the privacy protections in apt:
The SNI field issue does not exist when using Tor Onion Services. Package sizes would still be visible to network observers when using Onion Services, so TLS padding and pipelining would help there also.