3

I was looking at the installation instructions for VS Code today and found this step curious:

sudo apt install apt-transport-https

I see that there appears to be https transport available for apt:

$ ls -1 /usr/lib/apt/methods
cdrom
copy
file
ftp
gpgv
http
https
mirror
mirror+copy
mirror+file
mirror+ftp
mirror+http
mirror+https
rred
rsh
ssh
store

This made me curious about why Microsoft would have one install that package so I did some searching and ran across this article from cloud flare which points out that even fairly recent versions of Debian require additional steps to secure apt.

I was quite surprised to see that all of the urls in my sources.list are NOT https. My machine is running Ubuntu 20.04, upgraded from Ubuntu 18.04:

$ grep http /etc/apt/sources.list
# See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
deb http://us.archive.ubuntu.com/ubuntu/ focal main restricted
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates main restricted
deb http://us.archive.ubuntu.com/ubuntu/ focal universe
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates universe
deb http://us.archive.ubuntu.com/ubuntu/ focal multiverse
deb http://us.archive.ubuntu.com/ubuntu/ focal-updates multiverse
deb http://us.archive.ubuntu.com/ubuntu/ focal-backports main restricted universe multiverse
# deb http://archive.canonical.com/ubuntu focal partner
# deb-src http://archive.canonical.com/ubuntu focal partner
deb http://security.ubuntu.com/ubuntu focal-security main restricted
deb http://security.ubuntu.com/ubuntu focal-security universe
deb http://security.ubuntu.com/ubuntu focal-security multiverse

This seems less than ideal. It occurs to me that https can be more finicky and any failures might impede critical software updates, but this also seems painfully out of date from a security perspective. On the other hand, the information being transferred is open source software, so there isn't really any risk if someone snoops the packets in transit -- it's not sensitive information, is it?

Still, I'm wondering if there is risk in this. Is the HTTP protocol vulnerable to packet injection in transit? Can anyone lay out what risks there might be in using insecure HTTP traffic for apt?

S. Imp
  • 206
  • 1
  • 3
  • Similar to: https://security.stackexchange.com/questions/226317/are-downloads-from-http-connections-safe/226325 – mti2935 Apr 17 '21 at 21:12
  • @mti2935 that question is quite broad. I'd be happy to make mine more specific -- like ask how to fix this -- or if it's worth it to fix it? – S. Imp Apr 18 '21 at 01:14
  • OP, https provides two things that http doesn't provide: secrecy and integrity. Secrecy is not important for package downloads, because there is nothing sensitive about them. Integrity is important, however, to mitigate an attack like you describe, where the package is modified in transit by an attacker. To ensure integrity, a digital signature of the package is verified, after it is downloaded, using a public key pre-installed on the system. See https://askubuntu.com/questions/352952/are-repository-lists-secure-is-there-an-https-version for more info. – mti2935 Apr 18 '21 at 10:09

3 Answers3

6

apt (and other package managers) uses digital signatures to verify the authenticity of packages after downloading them. If a MITM modifies a package in transit, you get an error since the check fails. See https://help.ubuntu.com/community/SecureApt

Apt-get package management uses public key cryptography to authenticate downloaded packages.

Using HTTPS instead of HTTP hides some information from third parties, though. See https://manpages.ubuntu.com/manpages/focal/man1/apt-transport-https.1.html

A sufficiently capable attacker can still observe the communication partners and deeper analysis of the encrypted communication might still reveal important details.

user255746
  • 61
  • 1
  • 1
    it's my understanding that HTTPS provides additional assurance that the information is not spoofed. If you are relying on mere HTTP connections, there's a chance that the signatures might also be spoofed. – S. Imp Apr 18 '21 at 01:15
  • 5
    @S.Imp The signature cannot be spoofed without knowing the private key used for signing. – nobody Apr 18 '21 at 01:46
3

In addition to what the other answers mention, there's one more attack risk. Someone can deny you updates for a period.

While they can't forge packages and package lists, they can substitute them with previous, signed, versions, thus making your system believe that there's no new upgrades.

How apt-secure works is well outlined in this document from Debian. Note that MD5 is used in it, although it's been changed to better hashing algorithms. Apt on Debian 10 verifies package size, md5 and sha256-sum.

As you can see this was developed in 2003, and taken into use in 2005. At that time, https was exotic, and not mainstream. Debian has always relied on a lot of mirrors, and in 2005 most of those mirrors did not provide https, and many of them even used ftp. The Internet was simply different back then.

vidarlo
  • 12,850
  • 2
  • 35
  • 47
0

TLS, which is the encrypted tunnel used for HTTPS, provides three things: privacy (others cannot see the data transferred), integrity (others cannot modify or delete the data transferred), and authenticity (others cannot impersonate the remote machine).

Most APT repositories use a set of nested hashes (functionally equivalent to a Merkle tree) and digital signatures to provide integrity and authenticity. If someone tampers with the data, the hashes or signature will not match and the download will be rejected. In addition, APT repositories typically expire after a certain point, so that people cannot force the repositories to roll back to states where they were shipping insecure versions of software.

However, the lack of TLS means that you forgo privacy. In some situations, this might be okay. However, Debian and Ubuntu ship a wide variety of software, including software that's used to bypass censorship, encrypt data, and scan remote networks for vulnerabilities. In addition, it may contain material which is illegal in your jurisdiction, such as the aforementioned software, certain religious texts (shipped for the purpose of using them with software to read them), or software that can operate wireless hardware outside of regulatory compliance. It may be the case that you don't wish the entire Internet, including your ISP, government, and neighbors, to know that you're downloading such data, in which case you should use an HTTPS mirror after installing the apt-transport-https package.

My recommendation is to use both: TLS provides important guarantees about the path from the mirror server to you and protects your privacy, and the digital signatures on the archive protect you from malicious mirrors and allow you to verify the authenticity of the packages from the distro you expect.

bk2204
  • 7,828
  • 16
  • 15