Ubuntu ISOs aren't served securely and are trivially easy to MitM attack.
This vulnerability is still being exploited: https://www.bleepingcomputer.com/news/security/turkish-isp-s...
Just downloaded Ubuntu server for some local instances here at home and realized that I hit this path without even knowning.
[edit] Looks like ISO signatures are served over HTTP as well.
The only secure way to install is to somehow get their key, already have gpg installed and then verify that way.
It appears this to be the case, see "How to verify Ubuntu download" tutorial that provides detailed steps: https://tutorials.ubuntu.com/tutorial/tutorial-how-to-verify...
(If you plan to install an Operating System, then I believe some homework is in order -- you cannot expect the OS developers to spoon-feed you trivial security aspects that are expected to be a skill-set that you, the operating system installer, or System Administrator, do possess).
Isn't that a little hard if the verification keys(from that link) are served over HTTP[1][2]?
[1] http://releases.ubuntu.com/18.04/SHA256SUMS.gpg
[2] http://releases.ubuntu.com/?_ga=2.21478331.1690774166.154812...
keyserver.ubuntu.com is available over http as well as https, which means it's probably susceptible to a downgrade attack if you're mitming it - which would let you serve a bogus public key and therefore generate apparently valid signatures for the hash for a modified ISO.
That's not good...
As another poster noted the keyserver in that link will work over http so you're still susceptible to a possible downgrade attack.
Given how easy it is to get a LE cert these days it's making me question what other security decision Ubuntu is making that I'm not aware of or have the expertise to evaluate.
With regards to LE certs, I discussed elsewhere here the problems faced by the apt developers that make the obvious "just install a LE cert!" answer not actually workable for them - they rely heavily of volunteer run mirrors and local proxies. I don't know what Ubuntu's ISO download "server" really is underneath, it's possible they've got similar problems, where either they pay for all the bandwidth themselves, or they let people assume that an ssl secured connection to "ubuntu-mirror.usyd.edu.au" or "ubuntu-mirror.evilhacker.ru" is for some reason "safer" than an http connection...
In the abstract, this is true. In practice, however, the checksums are always downloaded from the same page as the OS and usually over the same (unencrypted) connection from the same servers.
Having said that, it seems keyserver.ubuntu.com is happy enough to allow connections via http instead of https, so there's a valid avenue to serve up a bogus public key...
That's a much smaller window of opportunity since if you're already a Ubuntu user you'll have a pre-existing copy of ubuntu-archive-keyring.gpg already, rather than trying to download a possibly mitm-ed public key at the same time as you download the ISO. But I must admit I boggled a little bit when I saw that keyserver.ubuntu.com happily server their public key over http instead of just https...
If you plan to publish an operating system, you should take effort to reduce this homework as much as is humanly possible. For every step where a user is expected to—but not explicitly required to—perform extra work to ensure their own security, the overwhelming majority of users will not take these extra steps.
Arguing that they "should" gets us nowhere.
That's less of a problem than it sounds.
Sure you can MITM and change the sig on the fly, but without the private key you cannot generate a valid sig for a modified IOS. (And if Ubuntu have had that private key stolen, there are much much deeper problems than the ISOs being served over http...)
On the other hand, I suspect it's probably fewer than single digit percentages of people who download the ISOs who then jump through the GPG hoops to check the signature is valid. And as with all PGP/GPG keys, you've got the bootstrapping problem of how do you know that your copy of ubuntu-archive-keyring.gpg is real to start with... (I've been to key signing parties, but not in the last ~30 years...)
Videolan and apt/get now. Here is why videolan doesn't do it: https://www.beauzee.fr/2017/07/04/videolan-and-https/
TLDR; They can't force HTTPS to 3rd parties, which is why they can't do it. It's not as simple as running LE.