This question already has an answer here:

I always see instructions for adding the Universe and Multiverse repositories that look something like the following:

sudo add-apt-repository -y "deb http://archive.ubuntu.com/ubuntu $(lsb_release -sc) main universe restricted multiverse"

Recently I tried editing this to use HTTPS instead and was dismayed to find that archive.ubuntu.com doesn't appear to respond to HTTPS. Now I wonder how feasible it would be, or what damage could be done, if an attacker were to successfully perform a man-in-the-middle attack here?

Am I being too paranoid, considering the role these repositories perform on a system?

marked as duplicate by user68186, mikewhatever, Eric Carvalho, muru, andrew.46 Apr 3 '16 at 2:12

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.


All the files downloaded by APT have a signature that allows the downloaded file to be verified against the public keys stored on your computer as being signed by Ubuntu and only Ubuntu. This verifies that the file you receive was authorised by Ubuntu at some stage and hasn't been modified or tampered with since.

A technical explanation of how this works is available from Ubuntu (and from Debian which uses the same system).

Because of the use of HTTP instead of HTTPS, yes eavesdroppers could see what files you are downloading, but privacy is not likely to be your concern in this case. A man-in-the-middle attempt to modify the packages to inject harmful code would still fail because it would break the signing mechanism.

One possible gotcha in this signing mechanism is that it doesn't guarantee that you are getting the most up-to-date version of the package (indeed, sometimes mirrors are slow to update). To help mitigate this problem, the signed release file includes a "Valid-Until" date after which all the files it references should be considered stale. It would be plausible for a man-in-the-middle to substitute an archive with an unmodified earlier version of the archive within this Valid-Until date and cause your APT to believe there are no updates. But they can't make any arbitrary modifications to packages nor could they go back in time past a certain point.

The signing mechanisms provide much better security than HTTPS in this kind of distributed environment where the files are mirrored over many servers not controlled by Ubuntu. In essence you only need to trust Ubuntu, not the mirror, so you need to prove that the files originally came from Ubuntu and have not been modified since - there's no need to verify the identity of the mirror.

Note that when you add a non-official repository to your sources list, such as a PPA, you will be receiving files that are not signed by Ubuntu. APT should warn you about this, because they haven't been signed by a certificate matching any of the public keys installed on your computer as authorised by Ubuntu.

Source: Are repository lists secure? Is there an HTTPS version?

  • 2
    A few MitM attacks I can think of: replay an old list of software so that security patches don't get installed, observe what software is installed by which updated packages are downloaded or even which PPAs are subscribed to. – Olathe Mar 17 '16 at 23:02
  • When I try to hit archive.ubuntu.com/ubuntu, the connection is refused. It's as if they are not listening on the HTTPS port. Is there some other URL we're supposed to use for HTTPS? – smitelli Mar 22 '16 at 22:10
  • I was wrong, i cant get that to work either. That was Debian... I've adjusted the answer accordingly. BTW Follow the link and read the comments for more information! And please give credit to the writer. – Izzno Mar 23 '16 at 14:36
  • 1
    A more annoying bug is that when you apt update, apt doesn't seem to do any checking on the HTTP response coming from the server, and will overwrite your index cache with whatever bogus info. An attacker can be subtle and feed you a stale index, but an annoying attacker can just feed you random data and totally break your unattended config/install setups. The fix is to trash the index cache and run apt update again. Furthermore, if there's an exploit in the code that reads /var/lib/apt/lists, an attacker can MITM you an input that will exploit that code next time you run apt. – Marius Jun 20 '17 at 0:00
  • are there any other mirrors that use https? – kapad Oct 11 '18 at 12:17

Not the answer you're looking for? Browse other questions tagged or ask your own question.