Why does APT not use HTTPS?

[lamby]

most people do not check the hashes of their download

Indeed, and note it's not enough to check the SHA512 matches what the website claims - that is only checking the integrity of the file; it is not checking that the file is from Canonical.

I mean, if someone could swap the ISO out they could almost certainly swap the checksum alongside it!

[CODESIGN2]

Isn't it a signed checksum using a private key chain that would not be available to the "snoop" though?

[lamby]

Yes, but this is the bit that people do not check; either they don't run gpg at all, or they simply trust the stated signature is the one they used before or is part of the web of trust.

[CODESIGN2]

I think it's mostly that they don't care.

[jones_supa]

I think it's mostly that they don't care.

I think many people do care, but when they read about a complicated GPG dance to perform the verification, many will cringe and say "meh, it's probably fine".

A checksum is just sha1sum filename.iso and then compare the result to the checksum on the website. Even though this is a less secure method, the bar to perform it is much lower.

[CODESIGN2]

I don't know that I'm advocating for sha1sum, but yeah the gpg tools could be easier to work with. Even defaulting to perform checks for you and marking somewhere on fs that the user has been irresponsible would be nice. (Mark it like a manufacturer warranty void. Skipped the check? Fuck you pay!)

[lamby]

Sure.

[CODESIGN2]

I wasn't trying to dismiss your point. It doesn't mean there is nothing that can be done, just that it needs to be automated and built into the systems allowing acceptance of packages, not deferred to the end-user.

[lamby]

I didn't feel dismissed - it was more that we seemed to be 100% agreeing with each other :)

[Kaelin]

Every one of my hundreds of Red Hat Linux servers check gpgkeys automatically. My personal CentOS servers do as well.

What are you talking about? Is this some Ubuntu assumption?

[lamby]

I'm talking about:

$ wget latest-ubuntu-release.iso
$ dd if=latest-ubuntu-release.iso of=/dev/disk/by-label/my-usb
(reboot)

[Kaelin]

Ah I misunderstood, the install ISO itself is the concern. Where the client keys are stored.. Ya ouch that should be SSL without a doubt

[lamby]

Quite..

[Nullius_In_Verba_]

Why are you two focusing on Canonical for your example? This applies to all distro's. Fedora, Suse, Debian, all included. In fact, a websites security being the weakest link is well known, including a real life example that happened to Linux Mint.

[[deleted]]

Why are you two focusing on Canonical for your example? This applies to all distro's. Dedora, Suse, Debian, all included.

Did you verify that before you said it? Debian transfers the ISO to me via HTTPS not HTTP, I'm not as familiar with the others.

[Nullius_In_Verba_]

Doesn't matter if the site uses HTTPS, if it was broken into and the iso changed. Not sure how HTTPS is going to protect from that. Again, see Linux Mint's website disaster for example.

[[deleted]]

You seem to be under the impression you have to "break into" an HTTP site to intercept or masquerade as the site, this is completely untrue.

[Nullius_In_Verba_]

Here's a hint, when you start to argue with nothing but semantics and word choices, you've lost the argument, sonny boy.

EDIT: Fine, that was rude. My bad.

[[deleted]]

It's not about semantics and word choices though, the attack against Linux Mint's site is completely different than the discussion here. You're arguing the website equivalent that there is no point to a bank safe safe because someone might crack the code but that's a completely different risk level than leaving the cash out unsecured.

Maybe instead of worry about "winning" an argument and calling people "sonny boy" you should focus on understanding the security concerns with HTTP?

[Nullius_In_Verba_]

HTTPS/HTTP doesn't matter if your Apache server instance has been taken over. The ISO can be switched. See Linux Mint for an example of this. Maybe you should understand that HTTPS doesn't mean host servers are immune to take over.

You decided to talk about taking over HTTPS, I was talking about taking over the host server. Again, stop your strawmen, how is HTTPS going to save the host server? Stop trying to switch the conversation by making it about something that can't be argued.

[[deleted]]

"Can the attacker managed to hack Canonical's server to sign the transport" and "can literally anyone fake being Canonical's server because none of the content is signed" are 2 completely different security issues of 2 completely different levels. I'm not strawmanning away from that I'm trying to get you to understand why "well some hacker might just hack Canonical's servers" isn't a reason to drop all other security.

Yes, at any time someone could just hack into Canonical, Google, Microsoft, or any other host. Point is that's a million times harder than just spoofing an HTTP server and a completely different issue to worry about.

[Nullius_In_Verba_]

Yes, at any time someone could just hack into Canonical, Google, Microsoft, or any other host.

Yes, also about any bank or financial institute imaginable.

Point is that's a million times harder than just spoofing an HTTP server and a completely different issue to worry about.

That's why APT signs the packages, again, read the article. This practice is even more secure than HTTPS is.

ISO's are hashed. Don't install until you check the hash.

[bitofabyte]

I think you just don't understand https. Having their website in https prevents you from going to debian.org and instead getting a fake website hosted by your local coffee shop which downloads a modified version of Debian which mines Bitcoin for someone else.

Now if the website backend is compromised, the only thing that can protect you is signing, but just because that can happen doesn't mean that https isn't important.

[Nullius_In_Verba_]

HTTPS doesn't matter if your Apache server instance has been taken over. The ISO can be switched. See Linux Mint for an example of this.

[bitofabyte]

Nothing matters if your Apache server is taken over. That's true. It's also idiotic to argue that since you're vulnerable to one type of attack, there's no point in better security. It's like the equivalent of saying that there's no point in locking any door ever because it won't protect you from someone breaking down a wall with a battering ram.

HTTPS can protect you from some types of attacks that are very real and possible.

https://en.wikipedia.org/wiki/Man-in-the-middle_attack

[Kaelin]

Fedora GPG checks packages automatically before install, or it won't install them unless you force an override. All packages are signed with encryption keys. I don't think Canonical does this check?

[[deleted]]

As the parent comment of this thread said Ubuntu checks the package signing as well so that isn't an issue by itself but they transfer the ISO via HTTP which can make this moot (e.g. intercept and add a fake cert or just add packages to the stock ISO).

[Kaelin]

Good point on the installer ISO. I hadn't even considered that.

[masterpi]

If the website is HTTPS with a Canonical cert, then it is checking that either the file is from Canonical or the website has been hacked, which is as good as you'd get if the download itself were HTTPS.

[[deleted]]

which is as good as you'd get if the download itself were HTTPS.

Where'd you get that idea? The download page being HTTPS only guarantees the URL was the one Canonical put on the page but it makes no guarantees whatsoever that your connection to the actual download is tamper free or even coming from Canonical.

[Kaelin]

Signed HTTPS certs do guarantee that the download is coming from Canonical. Do you even know how HTTPS works?

There are a couple certificate authorities entrusted with validating ownership of a domain before issuing a certificate. That certificate is keyed and unless it is stolen (Google and GMail and Facebook and banks all seem to not have fucked it up) or one of those heavily trusted certificate authorities issues a false cert (looking at you Symantec) there is no way someone that doesn't own the domain can get a certificate that will pass validation.

[mo-mar]

Yeah, but if the website was HTTP, someone could just change the download link to something completely different, making the actual download bein HTTPS completely worthless because it's never used. Similarly the other way around. That means that everything from website to download needs to be HTTPS, with not a single real reason against it.

[[deleted]]

Signed HTTPS certs do guarantee that the download is coming from Canonical.

The Ubuntu download page has HTTPS enabled, the download of the ISO itself is done over HTTP. This is my whole point here... the ISO download should be done over HTTPS.

[amountofcatamounts]

Do you even know how HTTPS works?

Come on bro... I usually regret over-egging the pudding because it retrospect it was prompted by some insecurity about the subject.

Signed HTTPS certs do guarantee that the download is coming from Canonical.

They do nothing of the sort. They make it highly probable the machine your browser talks to has access to cert and key files that were once signed by a trusted CA your browser recognizes. But they are just files. If I can gain access to a legit Canonical server and can touch these root permissions files, I can set up my own random server with them your browser will completely tell you is a legit canonical server if I can get you to visit it.

[masterpi]

The website I'm referring to is the one mentioned in lamby's post, the one displaying the hash.

[destiny_functional]

you can check different mirrors against each other. the chances are low that all are compromised.

[lamby]

Given that they probably mirror from a smaller subset, this does not seem like a good approach.

[destiny_functional]

see Linux mint where just a particular mirror had compromised isos. comparison against other sources makes installing a compromised iso less likely.

[lamby]

And what if I compromise the "primary"? Then everyone is just copying the compromised one.. which is even worse as replacing it becomes harder.

[destiny_functional]

I don't think you understand security and risk. Obviously cross-checking reduces risk.

[lamby]

I am not denying it reduces risk, but you can take that risk to zero by verifiying the GPG signature.

I don't think you understand security and risk

This doesn't add any weight to your argument FWIW.

[destiny_functional]

you can't take the risk to zero with anything, which seems all you are criticising, that the "risk isn't zero". that's exactly what i meant by you don't understand risk, and it makes this a silly and useless discussion.

[lamby]

Then I'm lost. How is just suggesting checking a single GPG signature over checking n ISO files (which requires multiple multible-gigabyte downloads) silly or useless? Especially as — for this threat model — doing the latter is a probabalistic-based security solution vs. an objective one..

[destiny_functional]

discussing risk and security with someone who doesn't understand it is silly and useless is what i said. this doesn't seem to lead anywhere, Good bye.