Why doesn't Linux apt use HTTPS?

(This site represents the status quo as it was some time ago, particularly before CVE-2019-3462 . It does not represent my personal opinion nor that of Debian/Ubuntu.)

tl;dr

Accessing mirrors over HTTPS would not prevent a compromised mirror tampering with packages, so APT already has other mechanisms to guard against this.

Also, HTTPS would not stop a determined attacker deducing which apt packages your system was downloading (though this becomes more difficult).

However there may be other security benefits to using HTTPS for apt updates, in that it should greatly increase the difficulty for a man-in-the-middle attacker to exploit future bugs in APT, or to temporarily delay the delivery of Release files to end users.

Whether Debian or other distributions switch to HTTPS as a default will depend on the cost and difficulty of maintaining valid TLS certificates on the mirror network, plus considerations about caching in low-bandwith environments.

How can I use HTTPS for apt?

It has been possible to use HTTPS mirrors with apt for a long time, if your distribution’s mirror network supports it.

As a prerequisite, for versions of apt before 1.5 (i.e. Debian stretch and earlier) you must first install the apt-transport-https package. Later versions include https support by default.

If you are using Debian, update your /etc/apt/sources.list entries to point to the official https mirror redirector:

deb https://deb.debian.org/debian/ <dist> <suite>
deb-src https://deb.debian.org/debian/ <dist> <suite>

e.g. for Debian unstable:

deb https://deb.debian.org/debian/ unstable main
deb-src https://deb.debian.org/debian/ unstable main

For other distributions, consult your distribution’s documentation.

Does HTTPS guarantee the integrity of packages?

https is used to prevent intruders from being able to listen to communications between you and websites you visit, as well as to avoid data being modified without your knowledge.

HTTPS can not detect if malicious tampering has occurred on the disks of the server you are downloading from. There is little point “securely” transfering a compromised package.

How does APT guard against tampering?

Files obtained by APT are accompanied by their own signature which allows your system to check they originated from your distribution.

These signatures are checked against a small set of trusted keys already stored on your computer. Downloaded files are rejected by APT if they are signed by an unknown keyor are missing valid signatures. This ensures that the packages you are installing were authorised by your distribution and have not been modified or replaced since.

But what about privacy?

HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution’s mirror network it would be fairly obvious that you are downloading updates.

Furthermore, even over an encrypted connection it is not difficult to figure out which files you are downloading based on the size of the transfer. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.

What’s more important is not that your connection is encrypted but that the files you are installing haven’t been modified.

Overly trusting CAs

There are over 400 “Certificate Authorities” who may issue certificates for any domain. Many have poor security records and some are even explicitly controlled by governments.

This means that HTTPS provides little-to-no protection against a targeted attack on your distribution’s mirror network. You could limit the set of valid certificates that APT would accept, but that would be be error-prone and unlikely worth the additional hassle over the existing public-key scheme.

Why not provide HTTPS anyway?

Your distribution could cryptographically sign the files using the existing scheme and additionally serve the files over HTTPS to provide “defense in depth.”

However, providing a huge worldwide mirror network available over SSL is not only a complicated engineering task (requiring the secure exchange and storage of private keys), it implies a misleading level of security and privacy to end-users as described above.

A switch to HTTPS would also mean you could not take advantage of local proxy servers for speeding up access and would additionally prohibit many kinds of peer-to-peer mirroring where files are stored on servers not controlled directly by your distribution. This would disproportionately affect users in remote locales.

Ah, what about replay attacks?

One issue with a naïve signing mechanism is that it does not guarantee that you are seeing the most up-to-date version of the archive.

This can lead to a replay attack where an attacker substitutes an archive with an earlier—unmodified—version of the archive. This would prevent APT from noticing new security updates which they could then exploit.