How to use https with apt-get?

Question

Does apt-get use https or any kind of encryption? Is there a way to configure it to use it?

Solution 1

apt-get (and other package manipulation commands, which are a front-end to the same APT libraries) can use HTTP, HTTPS and FTP (and mounted filesystems). If you specify https:// URLs in /etc/apt/sources.list and /etc/apt/sources.list.d/*, then APT will use HTTPS.

APT verifies the signature of packages. So you do not need to have a form of transportation that provides data authentication. If an attacker modifies the files you're downloading, this will be noticed. Using a signature verification is better than using an HTTPS connection, because it'll detect an attack on the server you're downloading from, not just an attack in transit.

More precisely, the (simplified) data flow for a package is the following:

1. The package is produced on a build machine.
2. The package is signed on the build machine.
3. The signed package is copied to a download mirror.
4. You download the package.

HTTPS ensures that step 4 happens correctly. The package signatures ensure that steps 2 to 4 happen correctly.

In fact, there is one small benefit to HTTPS for step 4: the package signatures only ensure that the package is authentic. An attacker in step 4 could impersonate a legitimate server and serve stale versions of the package. For example, the attacker could prevent you from downloading any security updates, in the hope of exploiting a vulnerability on your machine that you would have patched if it wasn't for the attack. This isn't a very realistic scenario, because it requires an active attacker (so that would have to be someone in control of your Internet connection), but it could happen in principle.

The other benefit to HTTPS would be if you're trying to hide the fact that you're downloading Ubuntu packages from someone snooping on your network connection. Even then, the eavesdropper could see what host you're connecting to; if you connect to an Ubuntu mirror and download hundreds of megabytes, it's clear that you're downloading Ubuntu packages. The eavesdropper could also mostly figure out which packages you're downloading from the size of the files. So HTTPS would only be useful if you're downloading from a server that also offers other files of similar size — I don't see any point except for third-party packages, and only in very unusual circumstances.

To reiterate: the usual benefit of HTTPS, which is that you know you're connected to the real server, is useless when you're downloading Ubuntu packages. The signature verification on packages gives a stronger guarantee than what HTTPS can provide.

Solution 2

With APT, typically what is more important is not that your connection is encrypted, but that the files you are receiving haven't been tampered with.

APT has built-in signature verification to ensure this.

Encryption would prevent eavesdroppers from being able to see what you are downloading, but what you are actually downloading (and requesting) is pretty uncontroversial: it'll be the same as thousands of other Ubuntu users are downloading and the files contain nothing that isn't freely available on lots of servers. Still, if you need privacy about what packages in particular you're downloading, HTTPS can be used (specify it in your sources.list).

The signature verification that is built in to APT will ensure that the files you receive have not been tampered with. It doesn't really matter where the files come from and it's even possible to have proxies or reverse proxies in between you and the server to reduce server load or speed you up. The signature verification still ensures that you are getting the unmodified file, matching the signature that could only be cryptographically produced with the original file and a copy of Ubuntu's private key.

If you switch to HTTPS, then you won't be able to take advantage of proxy servers for speeding up access or reducing load anymore. And it wouldn't add any more assurance about non-tampering that APT's signature verification doesn't already give. It would, however, mean that eavesdroppers (such as your ISP) will not be able to see which packages you're downloading (which is not likely to be confidential, and as Gilles pointed out they could guess from the file size).

Solution 3

I think this question could use an answer with instructions for the layman, so…

APT still does not use HTTPS by default in daily builds of Ubuntu 19.10 (Eoan) (which is still in development). One can verify this by examining the /etc/apt/sources.list file and noting that all of the source URLs utilize the "http:" URL scheme.

To configure it to use HTTPS, one can follow the following instructions:

First, find a trustworthy official Ubuntu archive mirror that supports HTTPS:

1. Navigate to the Official Archive Mirrors for Ubuntu webpage.
2. In the table on that webpage, identify mirrors that are (A) hosted on websites you consider to be trustworthy, (B) have an "http:" mirror and, optionally, (C) meet your geographical proximity, server speed, and update freshness preferences.
3. In the table on that webpage, click an "http" link of a mirror identified in step (2) to visit the "http:" version of the mirror.
4. In the browser address bar, manually change "http:" in the webpage URL to "https:".
5. Navigate to the mirror again (via the "https:" URL) to see if it resolves.

For example, I consider the Wikimedia Foundation trustworthy, so I visited the http://mirrors.wikimedia.org/ubuntu/ mirror URL and subsequently changed it to https://mirrors.wikimedia.org/ubuntu/, which successfully resolves.

If you use Firefox (67.0.4) and have the HTTPS Everywhere (2019.6.27) extension installed with the "Encrypt All Sites Eligible" feature enabled (via the toolbar button panel), steps (4) and (5) can be omitted because the extension will automatically modify the URL to utilize HTTPS, allowing one to more immediately determine whether the "https:" version of the URL will resolve.

Two, update your APT sources list:

1. Execute the command sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup to backup your update sources list.
2. Replace the mirror base URL—shown here as https://mirrors.wikimedia.org—in the command sudo sed --in-place --regexp-extended 's http://(us\.archive\.ubuntu\.com|security\.ubuntu\.com) https://mirrors.wikimedia.org g' /etc/apt/sources.list with the mirror base URL of your preferred mirror and, then, execute the command.

Thirdly, you should examine the contents of the /etc/apt/sources.list.d/ directory for "http:" sources that might be changed to "https:" after installing software from outside the Ubuntu archive.

For example, Microsoft's Visual Studio Code package adds a vscode.list file to this directory that specifies an "http:" URL. Simple changing the URL scheme from "http:" to "https:" allows updates over HTTPS.

Consider backing up any such source files before modifying them.

Lastly, perform an update to ensure that updates will work correctly:

1. Execute the sudo apt-get update command.
2. If that doesn't work as expected, restore the backup source list file(s) you made by executing the sudo cp /etc/apt/sources.list.backup /etc/apt/sources.list command.

It's also worth noting that there's an apt-transport-https package to add HTTPS support to APT. However, this package is apparently unnecessary according to the webpage https://launchpad.net/ubuntu/eoan/+package/apt-transport-https and has not been needed since APT 1.5 according to the information shown after executing the command apt-cache show apt-transport-https.

Solution 4

Recent APT releases have TLS support built in, so you simply need to replace your package-repository mirror URLs with https-prefixed ones. For Debian, it could look like this:

deb https://deb.debian.org/debian/ stretch main
deb https://deb.debian.org/debian-security stretch/updates main
deb https://deb.debian.org/debian/ stretch-updates main

This is useful, even though APT includes its own signature protocol to ensure packages aren't tampered with, because there can be bugs in APT (as there have been: CVE-2016-1252, CVE-2019-3462). The HTTP/TLS protocols and their ciphers are subject to intense scrutiny, so a severe zero-day vulnerability is much less likely if you add this layer of security.

View more solutions

Comments

[thomasrutter]

It's not that it's less secure, it's that it's less relevant to what you are trying to protect. With APT, encrypting the contents of your transaction is not so important, because what you're downloading is very uncontroversial: it's just the same Ubuntu packages that lots of people download. But what is important, is ensuring that the files as you receive them haven't been tampered with.

[h3.]

@EliahKagan See my edit. HTTPS and the package signatures protect different parts of the chain. HTTPS ensures that the data you download comes from the server that you contacted, but it can't guarantee that the data served by the server is the data you're after. The package signatures guarantee that the data you obtain are genuine. There is a small benefit to HTTPS, which is that it prevents an attacker from serving stale data, but I don't think this would be a very practical attack.

[h3.]

HTTPS won't give much privacy, because the size of the files is visible. There is in fact a small benefit to HTTPS, which is that it ensures that an attacker in control of your network connection cannot silently slip in stale data. It's a bit far-fetched.

[thomasrutter]

Good points. By "stale data" I presume you mean a man-in-the-middle setting up a version of the Ubuntu mirror comprised of slightly earlier versions, but still unaltered from what Ubuntu had signed at the time.

[Eliah Kagan]

Gilles: Thanks! @neon_overload: HTTPS digitally signs (as well as encrypting) the data the server is offering. So it's not just (or really hardly at all) about keeping people from knowing what packages I'm downloading. Gilles explains it best, I think, in pointing out that since I don't know the server's copy hasn't been tampered with, I should be verifying the package file's original signature instead.

[h3.]

Yes, that's it. Don't hesitate to point out if I'm a bit jargony — I need to keep in mind that this is Ask Ubuntu and not Information Security.

[ish]

The repository (update server) must support https/SSL for this to work. The main archive.ubuntu.com does not. You can check in your browser if a server supports it by prefixing https:// to the URL and seeing if you get a list of directories, etc.

[h3.]

@strapakowsky As izx writes, you need to use a repository that serves HTTPS. Many repositories don't, because it means additional load on the server and on the network infrastructure (you can't cache HTTPS, and packages are big files that don't change much so there's a lot of interest in caching them).

[tumbleweed]

"An attacker in step 4 could impersonate a legitimate server and serve stale versions of the package." Actually, we protect against this by giving package information an expiry date. APT will warn after this date that your mirror is stale.

[h3.]

@tumbleweed Oh, that's good. I didn't know that, thanks. This reduces the window of opportunity, but doesn't remove the threat. An attacker would be most likely to serve the next-to-last version of the file (to exploit a just-released vulnerability), which is often not expired yet. Still, I consider this a pretty unlikely threat.

[Simón]

So, if archive.ubuntu.com does not support HTTPS. Anyone knows of a server that does?

[Eliah Kagan]

@Simón You might want to post a new question specifically about this. If you ask a question just about what (if any) mirrors exist that support https, and link to this question with an explanation of how you are not asking anything deeper about how APT works with https, you might get an answer.

[Shnatsel]

Here's a list of all 15 mirrors that support HTTPS along with a script that generates the list: pastebin.com/QY2TQ1dq

[didi_X8]

Some months ago I would have agreed with this answer. I changed my opinion after reading that: citizenlab.org/2014/08/cat-video-and-the-death-of-clear-text I don't see how signatures can help against such an attack unless they are transmitted over a secure channel (the package contents itself could still be delivered over unencrypted channel, assuming that the hashing algorithm is strong enough).

[h3.]

@didi_X8 Signatures do prevent man-in-the-middle attacks (except for hiding updates by serving old copies of the package list). I've only skimmed the article, does it say anything other than “lots of people could MITM you”? You do need a trust anchor to start with, of course.

[didi_X8]

@Gilles you're right, I confused signatures with hashes (like git). The article mainly shows that MITM is probably happening on a larger scale then maybe most of us thought.

[VarunAgw]

If I am right, I read somewhere signing package using GPG is optional. So how it works in that case?

[TheGreatContini]

But how does your machine get the right public key that is used to sign the packages? In other words, what prevents the attacker from signing something with his key and substituting his public key so that apt will accept the downloaded packages? There needs to be a way of verifying public keys to make this process secure.

[h3.]

@TheGreatContini The public key is part of the initial installation image. You need to download that over HTTPS to bootstrap the security. HTTPS, in turn, uses a certificate chain which goes back to some signatures that shipped with the browser or OS that you used to download the installation image.

[Marius]

There seems to be a big hole in apt -- when you apt update and there's a man in the middle feeding you bogus indexes, apt happily takes whatever the man in the middle gives you and writes it in /var/lib/apt/lists. This isn't just with an evil man in the middle, but like if you're on hotel WiFi and get redirected to a login page, if you run apt update before you logged in, your /var/lib/apt/lists will get trashed with the hotel homepage HTML. BOGUS! Anyway basic TLS cert checking would rule this out immediately.

[thomasrutter]

@Marius this isn't supposed to be possible due to verification, which covers the lists as well as the packages. If you have reproduced this with a standard Apt installation you should report it to the maintainer.

[gd1]

@Gilles While I get your point, I cannot help but think that, given the tiny cost of HTTPS nowadays, I'd rather not broadcast the list of packets installed on my system and instead have eavesdroppers pay at least a bit of effort. The Information Security community seems to have an "if it's not bulletproof let's not bother" attitude that defies my (possibly misinformed) common sense. I guess I don't understand the threat model. Do we really have out there an army of competent and motivated attackers? I thought that if the attack is not commodified, most wannabe attackers won't even try.

[thomasrutter]

@gd1 when this was written HTTPS was seen as a lot more "optional" than it is now. Nowadays you may as well use HTTPS if your mirror supports it - I don't know how many of them do. Everything above is still true though, in that HTTPS would not provide any security against tampering since it's a mirror network run by unofficial third parties anyway. Any benefit HTTPS would provide would be dependent on you trusting the particular mirror you're downloading from.

[gd1]

Never thought HTTPS could provide security against tampering in this scenario. My comment was mildly questioning Gilles’s point that the additional privacy HTTPS gives is not worth it, because the eavesdropper can figure out the file names from the sizes.

[Niklas Holm]

There has in fact been multiple exploits of apt (1, 2) that allows arbitrary code execution as root that would have been prevented if https was used instead of http. So https do provide real security benefit because sometimes bugs happen and the more layers of security you have the better.

[Niklas Holm]

"APT has built-in signature verification to ensure this". Sadly, apt also has built-in bugs that allows an MITM to tamper with that verification (see 1 and 2) and perform arbitrary code execution as root. These attacks would have been prevented if https was used instead of http. This proves that the defence in depth principle applies here as much as anywhere else.

[thomasrutter]

https between the user and the mirror would not prevent this if the MITM happens between the mirror and its upstream or if the mirror itself was compromised or is the attacker. Apt's signature verification is designed to protect this entire path, including if the mirror is hostile. You can update apt to protect from the recent vulnerability going forward.

[Leif Arne Storset]

Oops, I only now realize this site is Ask Ubuntu. :) I couldn't find a similar CDN solution for Ubuntu.

[Sqerstet]

Does not seem to be the case with PPA packages.

[Admin]

A good reason to use https, is when you are working in a virtual machine and your host is a Windows machine that is running antivirus. The antivirus effectively works like a man-in-the-middle attacker. In my case I was updating Python packages in Kali Linux. Avast intercepted the connection and blocked some files. After switching Kali's apt repo to https (see kali.org/blog/kali-linux-repository-https-support) I no longer had this problem.