Ubuntu apt repos are not available via HTTPS

Bug #1464064 reported by Kevin M. Gallagher on 2015-06-11
198
This bug affects 36 people
Affects Status Importance Assigned to Milestone
Ubuntu
Undecided
Unassigned

Bug Description

While the apt-transport-https package is installed by default in Ubuntu, it does not seem to be possible to retrieve core Ubuntu packages or security updates via TLS. The main repositories such as these:

    http://security.ubuntu.com/ubuntu
    http://us.archive.ubuntu.com/ubuntu

Have no certificates and are not listening for connections on port 443. This also extends to downloading of the installation/ISO images.

While cryptographic signatures are employed for integrity and verification in both cases, and secure transport is of only limited benefit, there are several compelling reasons to support HTTPS in a consistent manner. HTTPS everywhere is now a best practice on the web, and through the US government and among major service providers. With the myriad ways in which plain HTTP connections can be intercepted and subverted, and the consumer demand for user privacy and security, we should be insisting on supporting strong encryption wherever possible. In this context, HTTPS is primarily beneficial for the following reasons:

* network attackers can't see what packages you're downloading and the specific software versions, thus profiling the server and assisting the targeting of vulnerabilities and zero-day attacks against it
* a sophisticated attacker with possession of a compromised package signing key can't leverage a "QUANTUM insert"-esque technique to redirect to a malicious .deb
* an attacker able to passively sniff the network traffic would not be able to use fingerprint techniques to find/identify servers installing an exact set of packages specific to an environment the adversary is searching for
* it makes impersonating an apt repo (for example with the goal of blocking people from receiving security updates) more difficult

In conclusion, I recommend that Ubuntu deploy SSL certificates on these repositories, and encourage mirrors to follow suit. This would allow communities of users and developers, including those which require strong security assurances, to take advantage of TLS for installing software provided by Ubuntu when their use case demands it. We understand that this might require some extra effort, but think it's worth it based on the reasons cited above.

Have there been any discussions in the community about doing this, and what would be an appropriate venue for us to pursue this matter?

Micah Gersten (micahg) on 2015-06-11
information type: Public → Public Security

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1464064/+editstatus and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
information type: Public Security → Public
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubuntu:
status: New → Confirmed
Inoki  (inoki) wrote :

Agreed and supporting the idea. +1

Alan Bell (alanbell) wrote :

some mirrors, e.g. https://mirrors.kernel.org/ubuntu/ do support https already, however there are other issues that would arise, such as mirrors with broken certs, or certs that don't match the multiple dns names for the server (see https://mirrors.us.kernel.org/ubuntu/ for example) supporting https optionally on the Canonical run mirrors is probably a good thing to do, and increasing the encrypted traffic sloshing about on the internet is always a good thing to do (it puts the needles in a bigger haystack).

Robie Basak (racb) wrote :
Download full text (3.4 KiB)

This is not a -1, but I think it'd be useful to have some perspective here, rather than just the "no HTTPS the sky is falling" view.

> HTTPS everywhere is now a best practice on the web, and through the US government and among major service providers.

I don't agree with this as a justification. "HTTPS everywhere" has come out of a specific need. The justifications for its implementation do not automatically hold "everywhere", especially outside of web apps. That's not to say that HTTPS shouldn't be implemented here, just that the argument that "it has been justified elsewhere, therefore it is justified here" is not a valid one, especially because in the other cases no HTTPS means no protection, whereas we already use signed packages. Thus this particular argument is hardly "compelling". The pros and cons of HTTPS implementation for package repositories should be considered on its own merits.

> * network attackers can't see what packages you're downloading and the specific software versions, thus profiling the server and assisting the targeting of vulnerabilities and zero-day attacks against it

The published packages have well known sizes, so I think attackers probably can infer what an individual downloads based on size. That doesn't mean that we should not have HTTPS, but rather that it should not be assumed that HTTPS downloads of packages would automatically be private.

If you really want privacy of the packages you download, it would be more effective to operate a full local repository mirror.

> * a sophisticated attacker with possession of a compromised package signing key can't leverage a "QUANTUM insert"-esque technique to redirect to a malicious .deb

A "a compromised package signing key" sounds like a tall order to me. Far harder than a compromised mirror private SSL key, since the former doesn't need to be kept on machines with widespread exposure to the world. I suppose there's no harm in being protected by both, though, since the two would probably need to be compromised separately - though I suspect that so many other attack vectors would be opened up by a compromised packaging signing key that HTTPS to your mirror probably won't help you anyway. For example, what about "flashplugin-installer" (for those who have multiverse enabled) and its download of a binary blob outside the usual packaging system, only verified by a (package-)signed hash? If a packaging signing key were compromised, you'd get little protection from an HTTPS apt repository without this transfer also being on HTTPS.

> * an attacker able to passively sniff the network traffic would not be able to use fingerprint techniques to find/identify servers installing an exact set of packages specific to an environment the adversary is searching for

Note the fingerprint-by-size issue above - I don't think HTTPS will help you against sophisticated attackers here. Run a full local repository mirror instead if you care about this.

> * it makes impersonating an apt repo (for example with the goal of blocking people from receiving security updates) more difficult

Somewhat true I guess, though note that although I don't see it being used, apt is capable of some level ...

Read more...

Chris Glass (tribaal) wrote :

As a quick drive-by comment: HTTPS absolutely destroys package cacheability, which is a rather desirable feature for invariant, versionned and signed binary blobs (what deb packages are from an HTTP perspective).

Micah Lee (micahflee) wrote :

I think that the biggest issue with apt repositories not using https is that attackers can block updates and censor which packages can be installed.

Here's a story: Once I was on Amtrak, the train system run by a US federal government agency, and noticed that the wifi was being censored. I wanted to try to figure out exactly how it was being censored using OONI Probe [1], but I didn't have it installed. So I attempted installing it, but the Amtrak network blocked the download of some of the dependencies, so I failed in mapping the censorship that trip. I figured out that the network blocked all http downloads where the content-length header was greater than 10mb (to prevent bandwidth abuse or something), but Amtrak wouldn't have prevented me from installing this if the apt repositories used https.

This is more innocent that other attacks could be. An attacker could prevent the installation of security updates, or of specific packages that they didn't want people using, such as enigmail, pidgin-otr, anarchism, etc.

Fingerprinting installed software is also a big issue. Robie makes a good point that https won't necessarily prevent that, because of package file sizes, but I still think transport encryption is the first step to solving that problem (e.g. then packages could add padding). And using https would require the attacker to maintain a database of package versions and file sizes, for all repositories that victims maybe using, including arbitrary PPAs, rather than just looking for package names and versions in the URLs.

But also, while it's true that "other things use https" isn't necessarily a good justification for apt repos to follow suit, I do think it's past time that we completely stop using plaintext transport protocols for anything. Even when you're using http to download signed things (like software packages, or PGP keys from key servers), transport encryption makes network attacks, both passive and active, much harder and makes users safer.

[1] https://github.com/thetorproject/ooni-probe

Greg Williams (greg2lapa) wrote :

All repos should only operate over https. The networks we move across are hostile: http://blog.cryptographyengineering.com/2015/08/the-network-is-hostile.html

XL (x-l4936) wrote :

Could Launchpad at least allow mirrors to specify https links on the mirror list? I find Tsinghua University mirror (http://mirrors.tuna.tsinghua.edu.cn/ubuntu/) redirects http to https, and two mirrors set HSTS headers when requested over HTTPS (https://mirrors.wikimedia.org/ubuntu/, https://mirrors.cat.pdx.edu/ubuntu/). I think if mirrors are willing to prefer or enforce HTTPS, Ubuntu should allow them to use https in their mirror's URL.

Rolf Leggewie (r0lf) wrote :

some further relevant discussion: https://www.reddit.com/r/Ubuntu/comments/3q53kc/list_of_ubuntu_repository_mirrors_available_over/

I'd like to pitch in with my own story as to why I would like to have https mirrors, at least as an option. I frequently go to a country with one of the crappiest internet connection on earth. The local telco duopoly is doing things beyond stupid to keep the network from totally breaking down. One of this seems to be broken transparent mandatory caches with incorrect blobs for all kinds of things. Packages I download are frequently corrupted which sucks hard because then I have to remove the deb from /var/cache/apt/archive, fetch it manually over ssh from my server at home and pay for the data transfer again (which is expensive here). If I were able to use https, they couldn't fiddle with my connection as they currently do. For normal browsing I've already resorted to socksifying almost everything.

The arguments about MITM are very real, although in my case I don't believe it's a malignent attacker, but simply a lazy and incompetent telco.

Rolf Leggewie (r0lf) wrote :

BTW, I actually disagree with the opinion that "https everywhere" is a good thing. Cacheability goes down the drain and if done well that's what could really make the connectivity in a place like this bearable.

What do we get instead? Edge nodes for facebook and other junk. Facebook is already free to browse here while you have to pay for the general internet. That trend is unfortunately very likely to continue.

So, please offer the choice of https mirrors but generally it would be better if most people continue to download over non-encrypted connections.

Jones (hip13044b) wrote :

Come on guys this is a really obvious security flaw. I get the heebie-jeebies installing packages when living in an oppressive country. I understand how package signing works, but this doesn't give me any reassurance at all because it's only a SINGLE LAYER of security. I have no idea what kind of protection mechanisms there are on the signing key, and whether anyone's being bribed/hacked to give them up.

Multiple layers of security are standard practice.

Additionally, as far as adding privacy via https, yes it's possible to deduce which packages but https significantly increases the work involved in doing so, thus it's still worth it.

Dimitri John Ledkov (xnox) wrote :

"I have no idea what kind of protection mechanisms there are on the signing key, and whether anyone's being bribed/hacked to give them up." so you are willing to trust any number of backdoored https CAs? There are multiple public records of backdoored CA certificates than there are of broken gpg keys.

Tristan (supersluether) wrote :

Whether HTTPS should be used by default or not should be left up to the mirror operators, in my opinion. They are the ones that would have to purchase and maintain the SSL certificates (unless they use a free CA like Lets Encrypt). However, for the mirrors that DO support HTTPS, it should at least be properly listed and supported in the "Software & Updates" GUI. The "Choose a Download Server" screen has a selection box for protocol, but it only ever has HTTP as an option. This makes me wonder why it even exists, because it even shows HTTP when I select an FTP mirror. (unless it's supposed to change, and I somehow broke it)

There's even a question about this from 3 years ago: https://askubuntu.com/questions/416190/are-all-ubuntu-update-download-servers-http-only

I'm probably oversimplifying this by a lot, but couldn't we just change the mirror registration page[1] to include an HTTPS option, review it to make sure it works, and let the users choose that protocol?

[1] https://launchpad.net/ubuntu/+newmirror (only has HTTP, FTP, and Rsync as options)

Bryan Quigley (bryanquigley) wrote :

I've got a bug about adding HTTPS to repo mirrors page -https://bugs.launchpad.net/launchpad/+bug/1255120. As of right now, no one is working on it (rated Low), but contributions are of course welcome to this open source project.

Niklas Sombert (ytvwld) wrote :

Is this really a duplicate?

The other bug is about the update process using HTTP.
This bug is about the mirrors not supporting HTTPS.

On Tue, Jul 04, 2017 at 12:21:34PM -0000, Matthew Paul Thomas wrote:
> *** This bug is a duplicate of bug 1186793 ***

No, I don't think it is. That bug is about what apt does by default.
This bug is about what protocols Ubuntu makes available in its official
mirrors.

HTTPS could be made available but not be made default, for example. And
currently, it's quite possible for someone to run an HTTPS Ubuntu
mirror, and for users to configure apt with HTTPS against that mirror
instead.

kepler-211c (kepler-211c) wrote :

Hi, could you please set this to high priority? This is a serious security flaw.

Yes, the packages are signed. However, signing keys can be stolen. In today's world, multiple layers of security are mandatory.

This bug has ALREADY left a critical flaw gaping open, https://www.debian.org/security/2016/dsa-3733, and continues to be unresolved.

tags: added: artful
tags: added: bionic
Victoid (djvictoid) wrote :

I can't believe HTTPS hasn't been switched on in the 2.5 years since this bug was reported. It's a commonsense move that even Linus has made. There are truly no arguments against it. It's farcical to report kernel signatures, but then not provide either the package or the signature over a secure transport. What's the point in signing it at all? Kernel.org is distributing the releases over an HTTPS CDN with no problems, and Ubuntu is way behind the times on this.

Robie Basak (racb) wrote :

On Mon, Dec 25, 2017 at 08:46:16PM -0000, Victoid wrote:
> There are truly no arguments against it.

Yes there are. See comment 6, for example.

> What's the point in signing it at all?

To prevent malicious code injection.

Fixed security bugs aside (whether in openssl or in apt/gpg signing),
the current security mechanism works as designed.

Adding HTTPS as an additional layer would be nice, which is why this bug
remains open. But the sky is not falling. Please stop ignoring the other
arguments already made in this bug and pretend that it is.

Bodo Brance (bodobr) wrote :

Please mark this bug as security issue.

Yarwin Kolff (yungtravla) wrote :

Is it me or are the people who defend Ubuntu's lack of security deliberately avoiding the issue?

The checksums and ISO files on releases.ubuntu.com and archive.ubuntu.com (and possibly more) are 100% vulnerable to MITM attacks for *NON-APT USERS*.

Do not assume that the entire world is using APT... In fact, the MAJORITY of people who downloaded Ubuntu did so using their browser.

All these people are at risk of running a compromised Ubuntu installation.

You had the chance to fix this issue 3 years ago... I don't know what else to say.

Vivien GUEANT (vivienfr) wrote :

Is-it possible to reference on https://launchpad.net/ubuntu/+archivemirrors hosting Ubuntu mirror in http secure (https in addition of http and rsync)

Would it be possible to remove ftp, which is an obsolete protocol, and to add the possibility to the mirrors that wish to propose https in addition to http?

Note that Debian will no longer offer FTP from 1 November 2017: https://www.debian.org/News/2017/20170425.en.html the FTP protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons.

Another argument to switch to https mirrors: With some Wi-Fi networks, hash checksums are systematically false. Using https can not be impacted by software that modifies the contneu of http connections.

French screenshot of a download failed in http (ok after switching to https, https://fr.archive.ubuntu.com/ is available in https)

bc (jkhdfkasdf) wrote :

And now we have CVE-2019-3462 to remind us that running security critical software running as a privileged user downloading data that will be parsed, decoded, and acted upon from a trusted location (ie Ubuntu's official mirror locations), but without a TLS layer to provide identification, authentication, confidentiality, and integrity validation is a bad idea.

Vivien GUEANT (vivienfr) wrote :

CVE-2019-3462 : Remote Code Execution in apt/apt-get
=> https://justi.cz/security/2019/01/22/apt-rce.html

Is-it possible to reference on https://launchpad.net/ubuntu/+mirror/bouygues-telecom hosting Ubuntu mirror in http secure (https in addition of http and rsync)

Would it be possible to remove ftp, which is an obsolete protocol, and to add the possibility to the mirrors that wish to propose https in addition to http?

Note that Debian will no longer offer FTP from 1 November 2017: https://www.debian.org/News/2017/20170425.en.html the FTP protocol is inefficient and requires adding awkward kludges to firewalls and load-balancing daemons.

Bryan Quigley (bryanquigley) wrote :

@vivienfr - please see this bug for listing HTTPS on the mirrors - https://bugs.launchpad.net/launchpad/+bug/1255120

A. Denton (aquina) wrote :

With regards to CVE-2019-3462, my organization agrees with the statement made on NSA QUANTUM: https://twitter.com/TRONDELTA/status/1087810526539931649

On behalf of my intelligence organization, I think it would be much better, if Canonical servers would require TLS >= 1.2 encryption (HSTS and ECDHE preferred) and thus identify themselves properly, so machines/users would be able make sure who they are talking/connecting to.

We think that would definitely make MITM and MOTS attacks more difficult. Personally, I'm aware of the existing signature scheme, i.e. present package security. Nonetheless, it does not seem to address the problem of transport security; especially the lack of identification. Therefore, I simply consider the assertions of whydoesaptnotusehttps.com as wrong.

There is also a research paper named "A Look In the Mirror: Attacks on Package Managers" (https://isis.poly.edu/~jcappos/papers/cappos_mirror_ccs_08.pdf), which showed that both APT and YUM repositories are vulnerable to replay attacks, in case the repository is accessed via HTTP (even with valid GPG signatures used).

In addition to that, Launchpad bug https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1647467 showed, that transport security sometimes may reduce the impact of known vulnerabilities and exposures.

Given the present state of things, I agree, on behalf of the members of my organization, that TLS should be optional, at least for a transitional period of LTS (5) years. We strongly recommend the decision makers at Canonical to act professionally on this and make a change soon.

Andy Brody (abrody) wrote :

Ubuntu's reliance solely on PGP signatures for package and .iso download security puts the community at risk.

There have been several APT vulnerabilities in the past few years that create remote code execution vulnerabilities for Ubuntu systems. It's irresponsible not to give system operators any option to protect against these vulnerabilities.

Every LTS release since 10.04 has been affected by at least one RCE vulnerability in APT that would have been mitigated by HTTPS mirrors.

https://usn.ubuntu.com/3863-1/ CVE-2019-3462
https://usn.ubuntu.com/3156-1/ CVE-2016-1252
https://usn.ubuntu.com/2353-1/ CVE-2014-6273
https://usn.ubuntu.com/2348-1/ CVE-2014-0487, CVE-2014-0488, CVE-2014-0489, CVE-2014-0490
https://usn.ubuntu.com/2246-1/ CVE-2014-0478
https://usn.ubuntu.com/1762-1/ CVE-2013-1051

Vulnerabilities like these are severe because they make it difficult if not impossible to securely bootstrap an Ubuntu system from an official release CD image.

It's especially egregious that security.ubuntu.com is not available over TLS, since many systems continue to refer to http://security.ubuntu.com even when they use a separate primary mirror that supports HTTPS.

Besides preventing remote code execution, HTTPS would also improve confidentiality.

Because Launchpad PPAs are only available over insecure HTTP, anyone using a PPA that belongs to them will disclose their identity over the network whenever apt update is run, which can be as often as multiple times daily.

It's particularly inexcusable that ppa.launchpad.net doesn't deliver packages over HTTPS because even though it does have a valid HTTPS certificate, it responds with a 404 Not Found instead of returning PPA content. [1]

There are many areas of the Internet community where the consensus has changed from HTTP as the default to secure HTTPS as the default. U.S. Government policy now requires HTTPS for all U.S. federal websites and web services, drawing no distinction between browser and non-browser use cases. [2] The W3C now recommends that the web platform should actively prefer HTTPS. [3] The IAB recommends that all new protocols use encryption for confidentiality. [4] Google Chrome has moved over the past few years to treat HTTPS as the default, explicitly marking plaintext HTTP connections as non-secure via a warning icon rather than a neutral presentation. [5] The IETF declared in RFC 7258 that pervasive monitoring is an attack that the Internet community should address through encryption and other means. [6]

It's long past time for Ubuntu to follow suit.

[1] e.g. https://ppa.launchpad.net/kubuntu-ci/stable/ubuntu/dists/bionic/Release returns 404, but works over insecure HTTP
[2] https://https.cio.gov/
[3] https://www.w3.org/2001/tag/doc/web-https
[4] https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/
[5] https://www.blog.google/products/chrome/milestone-chrome-security-marking-http-not-secure/
[6] https://tools.ietf.org/html/rfc7258

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers