Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use APT over HTTPS whenever possible #3286

Open
eloquence opened this issue Apr 18, 2018 · 4 comments · May be fixed by #7438
Open

Use APT over HTTPS whenever possible #3286

eloquence opened this issue Apr 18, 2018 · 4 comments · May be fixed by #7438

Comments

@eloquence
Copy link
Member

eloquence commented Apr 18, 2018

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:

*.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
Copy link
Member

legoktm commented Apr 27, 2018

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
Copy link
Contributor

emkll commented Apr 27, 2018

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 #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 Unauthenticated packages installed on app and mon servers during initial provisioning #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
Copy link
Member

legoktm commented Sep 30, 2022

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.)

@legoktm
Copy link
Member

legoktm commented Feb 3, 2025

Just checked and last month Ubuntu enabled HTTPS on their primary repositories \o/

https://bugs.launchpad.net/ubuntu/+bug/1464064 (see around comment 41).

We don't have a mechanism to switch existing apt sources.list, but we could just do this change in ansible + noble-migration and get away with it.

legoktm added a commit that referenced this issue Feb 3, 2025
Ubuntu now supports HTTPS on their primary mirrors, including
archive.ubuntu.com and security.ubuntu.com.

While APT verifies integrity using PGP signatures, there have been a few
vulnerabilities in APT that would've been prevented by also layering TLS
on top.

No attempt is made to update the configuration on existing instances;
instead this change will be made during the noble migration.

Fixes #3286.
@legoktm legoktm linked a pull request Feb 3, 2025 that will close this issue
2 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants