Ubuntu apt repos are not available via HTTPS

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

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

Agreed and supporting the idea. +1

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

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

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

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

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

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.

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.

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.

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.

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

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)

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.

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.

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.

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.

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.

Please mark this bug as security issue.

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.

Proof of Concept:
https://twitter.com/yungtravla/status/1013275701078683648

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)

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.

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.

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

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.

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

I cannot believe that Canonical has not decided to use https for all their apt repositories.
- it is very easy to setup https sites
- the users should at least have the choice between http and https to accommodate with die hard http fans (fanatics?)

Maybe those year old arguments in favor of https may sway some votes: https://blog.packagecloud.io/eng/2018/02/21/attacks-against-secure-apt-repositories

The only solution ATM is to check https://www.reddit.com/r/Ubuntu/comments/3q53kc/list_of_ubuntu_repository_mirrors_available_over/ an chose a nearby mirror.

Then compare http://security.ubuntu.com/ubuntu/dists/bionic-security/InRelease and your mirror, e.g. https://ftp.fau.de/ubuntu/dists/bionic-security/InRelease (mirror of the FAU (university) located in Germany) and make sure "Date:" in the top section of the InRelease file is equivalent (not more off than 6 to 12 hrs) between the two files.

Then adjust your /etc/apt/sources.list e.g. like this:

## Main repository for Ubuntu distributions. This line was auto-added in
## 2018 to provide a fallback, in case no network mirror is available.
# deb cdrom:[Xubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725)]/ bionic main restricted
# deb cdrom:[Xubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725)]/ bionic universe
# deb cdrom:[Xubuntu 18.04.1 LTS _Bionic Beaver_ - Release amd64 (20180725)]/ bionic multiverse

## See http://help.ubuntu.com/community/UpgradeNotes for how to upgrade to
## newer versions of the distribution.
## Major bug fix updates are produced after the final release of the
## distribution.
deb https://ftp.fau.de/ubuntu/ bionic main restricted
deb-src https://ftp.fau.de/ubuntu/ bionic main restricted
deb https://ftp.fau.de/ubuntu/ bionic-updates main restricted
deb-src https://ftp.fau.de/ubuntu/ bionic-updates main restricted
deb https://ftp.fau.de/ubuntu/ bionic-security main restricted
deb-src https://ftp.fau.de/ubuntu/ bionic-security main restricted

## N.B. software from this repository may not have been tested as
## extensively as that contained in the main release, although it includes
## newer versions of some applications which may provide useful features.
## Also, please note that software in backports WILL NOT receive any review
## or updates from the Ubuntu security team.
deb https://ftp.fau.de/ubuntu/ bionic-backports main restricted
deb https://ftp.fau.de/ubuntu/ bionic-backports universe multiverse

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team. Also, please note that software in universe WILL NOT receive any
## review or updates from the Ubuntu security team.
deb https://ftp.fau.de/ubuntu/ bionic universe
deb-src https://ftp.fau.de/ubuntu/ bionic universe
deb https://ftp.fau.de/ubuntu/ bionic-updates universe
deb-src https://ftp.fau.de/ubuntu/ bionic-updates universe
deb https://ftp.fau.de/ubuntu/ bionic-security universe
deb-src https://ftp.fau.de/ubuntu/ bionic-security universe

## N.B. software from this repository is ENTIRELY UNSUPPORTED by the Ubuntu
## team, and may not be under a free licence. Please satisfy yourself as to
## your rights to use the software. Also, please note that software in
## multiverse WILL NOT receive any review or updates from the Ubuntu
## security team.
deb https://ftp.fau.de/ubuntu/ bionic multiverse
deb-src https://ftp.fau.de/ubuntu/ bionic multiverse
deb https://ftp.fau.de/ubuntu/ bionic-updates multiverse
deb-src https://ftp.fau.de/ubuntu/ bionic-updates multiverse
deb https://ftp.fau.de/ubuntu/ bionic-security multiver...

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?

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.

Look at the example of a connection refused in http by the operator and which goes in https:

>to trust any number of backdoored https CAs?

Just use HTTP Public Key Pinning. It is was killed by Let's Encrypt as an HTTP extension, but nothing prevents you from using a cert preloaded to the device as a package. Of course it may require some modificatikns to apt.

>I cannot believe that Canonical has not decided to use https for all their apt repositories.

I easily can. Here are some facts:

1. Canonical is a UK-based company. Mark Shuttleworth is a British citizen.
2. UK politics is as usual has anti-crypto direction and in fact UK is a very oppressive regime. Some very nasty acts (https://en.wikipedia.org/wiki/Key_disclosure_law#United_Kingdom , https://en.wikipedia.org/wiki/RIPA_2000, https://en.wikipedia.org/wiki/IPA_2016 ) have been passed in UK like the ones mandating disclosure of crypto keys and providing the info in a decrypted form and legalizing the practice of cyberattacks and malware by UK govt agencies.
3. UK is a member of 5 Eyes and GCHQ had been doing internet surveillance.
4. Some persons who have harmed UK interests have died in very strange circumstancies.

The conclusion is simple: it is very unlikely that Mark Shuttleworth will harm UK interests (that would be a de-facto (but not necessarily de-jure, Kozma Prutkov's well-known aphorism postulates "At the sight of working ammunition how miserable are all the constitutions!") high treason) by introducing mitigations that can decrease UK agencies capabilities of committing the things that under legislation of other states (and UK itself, when they are committed not by its agencies) are felonies.

Let's not get carried away with conspiracy theories.

I understand the argument in favor of HTTP because it permits transparent caching of APT traffic. I think that transparent proxies were once a valid approach to reducing redundant network traffic. However, the time for untrusted, untrustable HTTP has long since passed, even for signed content.

The threat of bad actors attacking systems through HTTP is widespread and well-documented. The possibility of a 0-day in APT itself being used to attack systems that use HTTP for updates is very real. Consider that HTTP could be used to deliver stale packages that are subject to known and patched vulnerabilities.

Even ignoring the security concerns, which nobody should, many "transparent" HTTP caches are not at all transparent.

Proxies, both caching and non-caching, can and do block APT updates, whether due to malfunction, misconfiguration, or malware scanning false-positives.

A user that encounters a broken proxy may have no idea why their updates are failing. If the proxy is silently delivering stale indexes, there may be no sign that anything is wrong.

I have experienced this firsthand. I switched from the default Ubuntu mirror to a HTTPS mirror because a corporate firewall was blocking package updates. Using HTTPS resolved my problem. If HTTPS was the default, there never would have been a problem in the first place.

Any organization that wishes to benefit from caching APT traffic can and should run its own caching APT proxy or full repository mirror, not a "transparent" HTTP cache. I have done this myself, and it works. There is no longer any excuse for APT mirrors to default to HTTP.

/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\

Hi!

- Please set to high priority, for this still makes RCE possible (experience level: "rt-"pentester)
- All (20.04 default) repositories accept https except for "http://security.ubuntu.com/ubuntu focal-security InRelease" which is quite ironic.
- Reason to support https repositories:
 - Not enabled by default means that nobody is impacted negatively (Same with DNS over TLS).
 - Security in Depth principle, protect APT packages in transit (also) apart from only using verification.
 - Previous RCE CVE's "CVE-2016-1252 + CVE-2019-3462"
   https://security-tracker.debian.org/tracker/CVE-2016-1252
   https://security-tracker.debian.org/tracker/CVE-2019-3462

PLEASE NOTE THAT SOME BLACKHATS ARE TRYING TO GET THIS BUGFIX SWIPED AWAY. (I do not have an NDA and i am impacted by this, they can go fuck themselves for today.)

Kind Regards

/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\/!\

8 years later, we still have a lot of download servers available that use either unencrypted http or ftp. As an end user this confuses me. The "select best server" function of the Software & Updates tool will recommend a http server of a local alternative ISP located in my city, which seems to make sense, however after reading this thread I am very unsure whether I should instead choose another download server that is using https.

The Software & Updates tool does show the protocol before choosing a server from the server list, which helps a little.