Changing repositories to HTTPS

I will post here the references from the Stack Overflow thread:

1. The answer by "Niklas Holm" at Jan 30, 2019:
"
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 (https://www.debian.org/security/2016/dsa-3733) and here (https://www.debian.org/security/2019/dsa-4371).

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 (https://www.owasp.org/index.php/Defense_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.
"

2. The comment by "Charles Merriam" at Oct 6, 2013 at 18:39:
"
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.
"

The list of mirrors https://launchpad.net/ubuntu/+archivemirrors shows several ones that offer https. Why don't you select one of these?

An article by Cloud Flare:
https://blog.cloudflare.com/apt-transports/

Hey Manfred Hampl (m-hampl),

First, I wasn't aware of that list of mirrors.
Second, the default uses HTTP instead of HTTPS, while the default should be secured, meaning HTTPS.
I mean, the user would want to know that the system that it uses considers security its top priority.
Third, it is unclear to me which repositories I may change in "/etc/apt/sources.list" according to the list of mirrors that you provided, so now I need to study this issue.
It would've been better for all the users that the system (Ubuntu) would take care of this issue by default.

APT does work over HTTPS and you can use
HTTPS in an APT sources, update with source code.
You would have to compile it then update the package.
Not done automatically, you still have to go through the
whole "download-configure-compile-install" process manually.
APT adds its own cryptographic security with a key,
and works over HTTP and FTP well.

Hey Bernard Stafford (bernard010),

I had thought that Ubuntu is aimed for non-techie users.
Wouldn't it be Ubuntu's goal to make sure that its users receive a secured OS by default, without having to configure anything?

They do. The packages are signed and hashed. SO if packages have been tampered then they will fail their hash check and be rejected

Hey actionparsnip (andrew-woodhead666),

Did you read the references from the Stack overflow thread?
Specifically these:
1. The answer by "Niklas Holm" at Jan 30, 2019.
2. The comment by "Charles Merriam" at Oct 6, 2013 at 18:39.

i did

To actionparsnip (andrew-woodhead666) :

Then I assume that you prefer to stay with current configs (leaving HTTP instead of forcing HTTPS for everyone by default) despite of the red flags, such as *two* remote code execution exploits and package update prevention.
How is that secured, especially now that we have the solid knowledge that it is exploitable?

Because it relies on someone managing the Internet connection in between the user and the remote repo. If you can't trust your internal IT then you are screwed.

Alice runs Ubuntu. Bob controls Alice's Internet connection. Bob's proxy gives Alice an SSL certificate then re-requests the data from Web based URLs via HTTPS. When the traffic comes back, the traffic is decrypted then re-encrypted using the SSL given to Alice. This is common in large IT setups and has been in every IT environment I've worked in.
When the package is decrypted it can have all sorts of things done to it.... But hey... If its HTTPS it's definitely secure

No.... It's not.

The Ubuntu archive relies on GPG signatures, not SSL to protect integrity of updates.

In order to enable HTTPS in any meaningful way, we would have to stop relying on public mirroring, and would have to host all Ubuntu updates on Canonical hosted infrastructure. This isn't feasible.

That being said, if you believe there is an advantage to using HTTPS between a possibly untrusted mirror and your workstation, you can configure your apt sources list to specify one of the mirrors that offers HTTPS support:

https://launchpad.net/ubuntu/+archivemirrors

In this comment I will reply to both users "actionparsnip (andrew-woodhead666)" and "Marc Deslauriers (mdeslaur)".

Starting chronologically with my reply to "actionparsnip (andrew-woodhead666)":

Why you think that the scenario of an "internal IT" is the only scenario?
Other scenarios exist as well, such as:

1. Connecting to the internet via someone you don't really know, such as coffee shops, hotels, airports, etc.
This is especially critical for digital nomads.

2. Having your home internet connection somehow maliciously changed/managed.
For example, for the recent years, it has become popular that many people are renting a small place "under" the authority of an existing household.
That existing household is providing them with its electricity, water and internet connection (among other things).

3. Some countries may try to tamper with their citizens' internet data.

4. Using a "proxy" such as TOR or VPN or anything similar.

Regarding your scenario with Alice and Bob:
I don't understand why you think that Bob's proxy gives Alice a certificate?
The certificates should be provided either in the following ways (as far as I know):
1. Be provided into the installation of Ubuntu.
2. Be provided using PKI, Public Key Infrastructure (which is how it normally happens).

If the certificate is provided using either of the two methods which I listed above, then obviously the integrity of the repository data is properly kept and nothing malicious may be done by someone in the middle.

My reply to "Marc Deslauriers (mdeslaur)":

"In order to enable HTTPS in any meaningful way, we would have to stop relying on public mirroring, and would have to host all Ubuntu updates on Canonical hosted infrastructure. This isn't feasible."

Why you think this is the case?
Enabling HTTPS is trivial nowadays.
Any public mirror could enable HTTPS.

"That being said, if you believe there is an advantage to using HTTPS between a possibly untrusted mirror and your workstation, you can configure your apt sources list to specify one of the mirrors that offers HTTPS support:"

Another comment here told it to me as well, so I know that it is possible.
The problem is that HTTPS isn't being forced by default in the file "/etc/apt/sources.list", so HTTP easily appears there.
Obviously, mirrors cannot completely be trusted.
But the point is to reduce the possibility of an exploit for *all* of Ubuntu users, which are commonly *not* tech-savvy.
If we have a small, well defined, list of mirrors, then the possibility of them trying to do something malicious is MUCH LESS than the rest of the world.

-------------

I got to admit, I'm quite surprised that I need to have this discussion at all.
It is a solid fact that the currently used method is exploitable and two scenarios of remote code execution already took place and that didn't raise any red flag?

Are you sure that your references are valid?
A bug in Debian's apt program has nothing to do with http or https connection to the mirror server.
The same buggy apt package would have been transmitted also via https.

Manfred Hampl (m-hampl):

Though HTTPS makes sure to drastically minimize the list of potential malicious actors.
So if I'm connected via HTTPS to a repository server, then I know that my connection to that server is safe such that all the data's integrity is kept.
Who will be able to tamper with the data and cause a remote code execution via APT?
Only the server to which I'm connected.
What is the possibility of the server to perform that?
Much less than the rest of the world.

It is a simple (1 < 100000000) arithmetic.

If you are in a coffee shop and are worried about this stuff then you should have a VPN of sorts.

It's very common for companies to use a man in the middle certificate for the proxy. The communication between the user and the proxy uses one certificate (internal) and the proxy to the Web server etc uses the certificate presented by the external source.

Your issue in the situation is bob. Nothing more. Having SSL in the repos doesn't protect you from this form of connection. When someone "manages the conversation for you" there is a level of trust and they become your internal IT for a short spell. If you don't trust them then you are screwed.

"So if I'm connected via HTTPS to a repository server, then I know that my connection to that server is safe such that all the data's integrity is kept."

And if the package is secured by cryptographic signatures, then I can also be sure that the package's and its contents' integrity is kept.

In this comment I will reply to both users "actionparsnip (andrew-woodhead666)" and "Manfred Hampl (m-hampl)".

Starting chronologically with my reply to "actionparsnip (andrew-woodhead666)":

"If you are in a coffee shop and are worried about this stuff then you should have a VPN of sorts."

Well many "normies" which aren't tech-savvy normally don't have VPN.
Websites have HTTPS which protects these "normies".
Ubuntu is designed for these "normies" (or, at least supposed to).

I listed additional scenarios except for coffee shop.

The scenario of the workplace (with Internal IT and Bob issuing a certificate to Alice) is only *one* scenario which is common to places where people work.
In these scenarios, the Ubuntu is already pre-configured by IT so I don't think that this scenario is relevant.

Moreover, regarding the mirrors which are listed here:
https://launchpad.net/ubuntu/+archivemirrors

I noticed that the mirrors are being verified.
For example, if you click on the link of a mirror, you'll see something like:

"Last probe
This mirror was last verified 16 hours ago."

This only increases the need of HTTPS, because that the mirrors are already being checked against their content.
If we compare it to the rest of the world which may tamper with the HTTP data, they obviously it isn't being verified.

So, the validity of the "untrusted" mirrors is only *greater* due to this verification.

My reply to "Manfred Hampl (m-hampl)":

"And if the package is secured by cryptographic signatures, then I can also be sure that the package's and its contents' integrity is kept."

We've already seen exploits which circumvent this mechanism which verifies the contents of the packages.

Bob gets a job at Canonical. In this parallel universe the repos are using SSL. Bob pushes a local update to the Indian repository during the day for 1 hour with the relevant checksum and malicious deb for the vim package. Millions of users are affected but Bob winds back the change enough to be undetected.

You can "what if" all you like. SSL isn't a magic bullet to make everything better.

To "actionparsnip (andrew-woodhead666)":

First, that is a very unlikely scenario.
Second, as far as I know, every change is well documented and reported.
Third, that scenario is only *in addition* to all the other scenarios that I listed (meaning, it is being *added* to the list of possible scenarios which may risk the user.)

We can list scenarios all day but that doesn't delegitimize the fact that HTTPS significantly reduces the risk of the exploits that I've written in my comments above.

But you know what? Challenge accepted.

Additionally to forcing HTTPS instead of HTTP, we could also make every user as the "verification agent" of the repository which it uses.
So, the same code which verifies the repository will be applied by the user right before it performs the relevant installation/update using "apt".
This verification may be sent to Canonical Servers as part of the whole process, to make sure that the repository server is valid.
If it's invalid, then the server gets blacklisted and alert is sent.

Advantages to the above idea:
 * Saves computation time for Canonical servers (because doesn't need to perform the verification by the servers).
 * Verifies the servers by the users themselves, each and every time (ensures validity always).

I never wrote that "SSL" is magic, it was your assumption.

https://ubuntu.com/tutorials/how-to-verify-ubuntu#1-overview
https://askubuntu.com/questions/1032098/why-do-ubuntu-open-source-packages-have-gpg-key
https://unix.stackexchange.com/questions/96951/why-do-i-need-to-add-a-gpg-key-with-apt-key-before-adding-url-to-sources-list-an
https://help.ubuntu.com/community/GnuPrivacyGuardHowto

To Bernard Stafford (bernard010):

From your comment I conclude that you haven't read the previous comments that I wrote, so the contents of your reply doesn't change anything.

The packages verification with GPG existed (as far as I know) at the time of the two remote code execution exploits, therefore GPG signatures isn't enough.
The risk of the two remote code execution exploits could've been drastically minimized if HTTPS would've been used.

In addition, the packages verification with GPG existed (as far as I know) throughout the entire time that it was (and still is) possible to prevent updating packages for a user (as with the example given by "Charles Merriam" at Oct 6, 2013 at 18:39 in the stack overflow thread).

BTW, maybe it wasn't clear enough, but when I wrote that HTTPS should be used instead of HTTP, it obviously doesn't mean that we should avoid using GPG signatures to verify the packages.

I don't understand why you guys are "pushing away" this idea instead of embracing it and try to come up with a better solution.

If this was my product, I would've felt embarrassed to provide it to a customer this way.

If we want to increase Ubuntu's popularity, we'd better strive to make it more secure, which also means reducing the likelihood of using exploits.

Objecting to this approach is counterproductive as I haven't read any plausible explanation to the current default state of Ubuntu's configs regarding this matter.

"That being said, if you believe there is an advantage to using HTTPS between a possibly untrusted mirror and your workstation, you can configure your apt sources list to specify one of the mirrors that offers HTTPS support"
https://launchpad.net/ubuntu/+archivemirrors
You can pick your own mirror that is https .
This will not be changed for Ubuntu or Canonical.

If you want to "secure your trousers with belt and braces", then please activate https for the repositories that you use (see comment #2) on top of the GPG signature mechanism of apt.

Off the record, see https://www.privafy.com/resources/how-https-creates-a-false-sense-of-security/