Use APT over HTTPS whenever possible

[eloquence]

Originally filed by @emkll in our infrastructure repo on 2017-11-13:

Using TLS for APT would increase the difficulty of man-in-the-middle attacks at install/update time such as:

• Injecting malicious packages should a signing key be compromised or package/signature verification silently fails.
• Inspecting or preventing the install of certain packages on the host.

The following APT repos are used by SecureDrop:

• http://security.ubuntu.com/ubuntu trusty-security main
• http://security.ubuntu.com/ubuntu trusty-security main
• http://security.ubuntu.com/ubuntu trusty-security universe
• http://security.ubuntu.com/ubuntu trusty-security universe
• https://apt.freedom.press trusty main
• http://deb.torproject.org/torproject.org trusty main

*.ubuntu.com currently does not support HTTPS, but some mirrors do [0]. deb.torproject.org does, but it will soon be mirrored by apt.freedom.press

[0]https://www.reddit.com/r/Ubuntu/comments/3q53kc/list_of_ubuntu_repository_mirrors_available_over/

[legoktm]

If there are attacks/threats that HTTPS+APT mitigates, it would be nice to document them as counterpoints to https://whydoesaptnotusehttps.com/

I don't exactly understand the concerns mentioned in the ticket, but I also don't know the full threat model that secure drop is protecting against. I would be a bit concerned if a failed signature verification is ever treated as a silent failure though.

[emkll]

Thanks for chiming in @legoktm ! This ticket was initially created after we've uncovered an install-time vulnerability in SecureDrop due to packages signatures not being validated (see https://github.com/freedomofpress/securedrop/issues/2472).

While minor, I think that there would be incremental improvements to using HTTPS, but mostly defense-in-depth as stated by the link you mention:

• In #2472, HTTPS would have prevented potential man-in-the-middle injection of malicious packages.
• It seems like Ubuntu mirrors don't have a valid-until field specified in their Release file, which means that an adversary may be able to replay out-of-date packages.
• HTTPS would make it slightly more difficult for an adversary to identify which packages are being installed.

[legoktm]

4 years later, yeah, we should definitely switch to downloading fetching apt sources and packages over HTTPS. Specifically CVE-2019-3462 (writeup: https://justi.cz/security/2019/01/22/apt-rce.html) would've been stopped by using HTTPS. There are older MITM bugs in apt too, that's just the most recent one.

It's disappointing that Ubuntu still doesn't offer HTTPS on their official mirrors (Debian does). My suggestion would be to pick a mirror from an org that we already trust, like kernel.org, (in order of my personal trust, I would then go for Wikimedia, then OSUOSL) and use that.

Assuming apt's gpg verification works correctly, then a mirror can't push malicious packages on us since it still needs to be signed by the Ubuntu keyring.

A hostile mirror could:

• Prevent instances from getting security updates (doesn't even have to be hostile, could just be broken)
• Exploit gpg verification bugs in apt to get us to install malicious code.

If our preferred mirror went rogue, we would still be able to deploy updates via securedrop-config/apt.freedom.press to swap to a different mirror.

Alternatively we could host our own mirror. Technically it's straightforward, it just has high storage requirements (1.5TB of space, see https://wiki.ubuntu.com/Mirrors) that will keep growing, plus the bandwidth costs. (And because it's public on the internet, there wouldn't be a straightforward way to lock it down so only SecureDrops can use it.)