34

Are repository updates secure?

As a bear of little brain from the developer side, I cannot understand why the repository list is http://security.ubuntu.com and the other http(unsecured) sites listed in /etc/apt/sources.list. Without a certificate chain match this appears as "ask any responder for a list of packages to update" instead of "ask the ubuntu.com site..."

Can any network choose to spoof the update sites, and is this a common practice to provide a locally cached and vetted copy?

blade19899
  • 26,704
Charles Merriam
  • 461
  • 1
  • 4
  • 7

3 Answers3

35

Update 2022: Repository hosts/mirrors tend to support HTTPS now, so you may as well use it to give additional assurance on top of what APT provides. Read below for an explanation of why HTTPS alone wouldn't be enough to protect you, and why APT adds its own cryptographic security.

In short, there is security without HTTPS, because all the packages are cryptographically signed and APT verifies the signatures.

The APT system is a secure packaging solution in which packages are signed with keys known only to Ubuntu and APT verifies the signatures against the package using public keys in APT's keyring on your system. This effectively provides end to end assurance that the package is unmodified by anyone outside of Ubuntu regardless of whether you obtained it from an official Ubuntu server or some mirror somewhere.

Ubuntu's repository system was built (as part of Debian) in a way so you don't have to trust the mirror you use, just that they didn't modify the package since it was signed internally by the distribution. This allows for the repository to be decentralized and for any volunteer to set up a mirror.

So, for example, you could use example.com as a mirror - if you were to use HTTPS and verify that you really are talking to example.com, it doesn't tell you anything useful, such as whether that mirror is approved by your distribution (Ubuntu) or whether that mirror modifies the packages after it gets them from Ubuntu to add viruses, it just tells you that you're talking to example.com. But APT's built in signature verification does provide those assurances.

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

APT does work over HTTPS and you can use HTTPS in an APT sources entry to apply another level of assurance to your connection (if the repository you're using supports it). This can act as an additional safeguard on top of APT's, especially now that past concerns about additional overhead imposed by HTTPS connections are less relevant.

Arguments for using HTTPS:

Not using HTTPS can be a privacy concern, because eavesdroppers could see what files you are downloading, though privacy has not historically been considered to be concern in this case as they are publicly available files, and APT's verification can still detect modification. Nonetheless HTTPS could be used to make it harder for attackers to see what you are installing.

Another assurance that APT's signing mechanism doesn't provide is that the packages you are receiving are the latest available version. As a mitigation to this, the signed release file includes a "Valid-Until" date field after which the files it references should be considered out of date. It would be plausible for a man-in-the-middle or nefarious mirror to substitute an archive with an unmodified earlier version of the archive within this Valid-Until date and delay an update to a package for this time window. But they can't make any arbitrary modifications to packages nor could they go back in time past that point.

Another reason you may consider using HTTPS is to guard against flaws in APT's own signing and verification. Flaws in this have been discovered, and fixed, in the past.

thomasrutter
  • 36,774
  • 1
    Great! So the short version is "the transport layer is not secure, but each package is signed. There is no secure list of available updates and patches for existing security issues are not guaranteed to be delivered." – Charles Merriam Oct 03 '13 at 03:36
  • 2
    Not sure what you mean by "There is no secure list of available updates" but the release file and package lists are signed. It's just that it doesn't verify that your mirror is up to date. – thomasrutter Oct 03 '13 at 06:08
  • 3
    Er, if there is no way to verify that a mirror, or the main site, is up to date then there is no way to know if there are updates available, security updates or otherwise. That is, there is no secure list of available updates. – Charles Merriam Oct 04 '13 at 03:30
  • But how is that related to HTTP vs HTTPS? How would connecting to a mirror via HTTPS prove that it is up to date? I don't see what the point you're getting at is. – thomasrutter Oct 04 '13 at 04:13
  • 8
    Alice runs Ubuntu. Bob controls Alice's Internet connection. Bob cannot put a bad package into Alice's installation because each package is signed. There is some huge security flaw found in Ubuntu. Alice try's to find the updated package, but Bob removes all mention of the package from Alice's update check. Alice whacks a sysadmin and then pulls the update check via HTTPS from ubuntu.com verifying she is connected to the real website along a secure link. Now Alice sees the security update and Bob cannot hide it. – Charles Merriam Oct 06 '13 at 18:39
  • 1
    After digging around a bit I've discovered that signed release files contain an expiry date called "Valid-Until" which aim to prevent this very scenario - APT will refuse to trust a release file which has passed its expiry date unless you tell it to with -o Acquire::Check-Valid-Until=false (a useful command if testing APT an old snapshot of a repository, or if you want to force APT to use a stale, out-of-date mirror). This would limit Bob's ability to serve stale packages unnoticed to those within the valid date. – thomasrutter Oct 07 '13 at 03:54
  • Hmm.. A good ameliorating solution. Utterly obscure. Thank you. – Charles Merriam Oct 10 '13 at 02:15
  • 1
    @CharlesMerriam if there is any part of the update list missing or altered by Bob, Alice will see an error when she runs apt get. Either, "failed to retrieve" or gpg error from tampering with the list. Oh, and BTW even if the mirrors you are using are not up to date, there is NO mirror for http://security.ubuntu.com and you will see this url if you inspect the contents of the file /etc/apt/sources.list this way, security updates are ALWAYS up to date regardless if the mirrors are or not – mchid Apr 22 '15 at 03:00
  • Errr... mchid, Alice cannot get to security.ubuntu.com. It's not a mirror issue; Bob controls Alice's network connection. Alice will, per @thomasrutter, see a warning that the snapshot is out of date, eventually. – Charles Merriam Apr 23 '15 at 04:26
  • @CharlesMerriam Instead of https, dnscrypt will work much better. – mchid Jun 05 '15 at 09:40
  • 5
    This is of course the correct answer. But what I find strange is that no one seems to be worried about an eavesdropper compiling a list of all the packages you have installed in order, including which ones you've updated and which ones you haven't, to target their attack on known security vulnerabilities in those packages. – Teekin Nov 28 '16 at 12:22
  • 1
    I don't understand why they don't want to make it https. Whether it makes a huge difference or not, it is trivial to support it. If they want, they could even use Caddy to make it even easier to implement. https://caddyserver.com/ More energy was spent debating this issue, than would be spent simply setting up https. – rotten Aug 28 '18 at 21:56
  • Most of the major mirror servers already support it now. That decision is up to the individual mirror server. Most people will be able to find one near them that supports https. Note that this answer was written in 2013. Since then https has become more common globally. – thomasrutter Sep 03 '18 at 11:51
  • What about replay attacks? An attacker could serve an old vulnerable package that was signed by Ubuntu. – Aaron Franke Aug 22 '21 at 01:41
30

The top rated answer here is clearly outdated. Since then, there has been 2 serious remote code execution exploits found in apt because of buggy package verification. Security bulletins here and here.

This is much worse than the concerns about privacy/information leakage and stale package version; this enables arbitrary code execution as root, complete security failure. And the thing is: 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. The many claims floating around that https provides no or minimal security benefit in the context of apt is simply incorrect, as has been shown by these exploits.

The question then becomes if the security benefit of https is worth the cost in terms of caching, increased overhead etc. I can't answer that, but at the very least I think Ubuntu/Canonical/Launchpad should provide optional https endpoints for their repositories.

Niklas Holm
  • 460
  • 7
    Security is also about privacy, and HTTPS means will at the very least have a much harder time figuring out which packages and versions you are running. – l0b0 Feb 21 '19 at 07:06
  • I'll say though that as long as apt itself isn't having problems with this, http is fine. However, https gives a backup in case the gpg security (or how it uses it more accurately) messes up. – RoundDuckMan Feb 21 '19 at 10:13
  • I think, even if they try to be light on the transport volume and therefore expose the more massive downloads via http, at the very least the torrents and checksums/hashes (.md5, etc.) should be exposed securely via https. So that we had a means of verifying what we downloaded based on a reference obtained from a trusted source (identity). This seems all but safe as it is now ... :S – brezniczky Feb 09 '20 at 22:24
  • 1
    I am not too deeply into this, so please forgive any inaccuracies, but "someone else on the network can read or modify the website before you see it, putting you at risk" apparently is just unacceptable in case the result is an OS image.

    https://blog.mozilla.org/security/2017/01/20/communicating-the-dangers-of-non-secure-http/

     – brezniczky Feb 09 '20 at 22:30
  • Actually I faced problems that some customers have port 80 block on firewall (they have security policy on that with no exceptions at all). And thus they do not receives updates or they cannot install some packages. – Tomas Kubes Feb 08 '24 at 14:09
3

Important supplement：in fact, as upgrade and initial installation download online, it takes a lot of traffic, and the source of these traffic, that is, binary and text code streams, is reproducible. So there are a large number of gateways and cache devices on the Internet for it. A considerable number of ISPs had set up cache based on the http protocol in order to save the export bandwidth, and the https protocol cannot exist as a transparent cache.

Another reason is that the http-based mirroring program is much simpler, there is no need to verify the tls-ssl certificate, and no need to worry about certificate invalidation or web server configuration problems too.

Not too long ago, about 20 years, at beginning of Internet, https and Internet traffic were still very expensive gameplays. Therefore, http also included the ftp protocol, which is close to being obsolete, as the main way of delivering installation and update for software packages distribution online.

Similarly, Microsoft Windows and Office are also upgraded using http. You can observe that it is usually not the installation package downloaded from the Microsoft's server, but your ISP's self-built cache server.

J.Z
  • 131