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.
The threats
Now is a good time to reiterate the areas of concern:
- Package authenticity (software can be modified while being downloaded).
- Repository availability (whole sites or specific URL paths can be selectively blocked by the network).
- Package availability (software security updates can be individually blocked).
- Who is downloading what package (currently visible to anyone who can see the network traffic, including open wifi, etc.).
- Vulnerabilities in apt or its signature validation (apt can be exploited, authenticity checks can be bypassed).
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 risks of adding HTTPS
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.
Things that can be improved
There are some additional bits of metadata that can be protected when using HTTPS, thereby further improving the privacy protections in apt:
- With TLSv1.3 Record Padding, TLS streams can be padded, which would obscure the size of the packages being downloaded from network observers.
Pipelining downloads through a reused HTTPS connection makes it even more difficult for the network observer to track packages by size.Update 2021-12-09: It turns out that apt is already pipelining requests by default, so that can be crossed off the list of things to be improved.- The Server Name Indication (SNI) field in TLS will leak the domain name in plaintext. The upcoming TLS Encrypted Client Hello standard will encrypt that.
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.