"Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories." No directory or direct links are provided. Verification instructions are not linked to from the download page.
And here, along the images, there are difficult to miss (and GPG-signed) SHA256SUMS and SHA512SUMS files. Moreover, the last page clearly links the verification instructions in the "How can I verify my download is correct and exactly what has been created by Debian?" section.
IMHO, if a signature is offered, and you have the capability of verifying it, this trumps HTTP, HTTPS, HSTS, checksums, etc.
HTTPS can be MITMed by anybody with a root certificate (or who is able to dupe the holder of a root certificate). Signatures rely on (at best) multiple hosts or domains not being compromised. You can also mirror and cache distro ISOs when retrieved by HTTP or bittorrent.
In the end, who cares how you downloaded it, so long as you can verify it with a GPG signature?
If you get the signature from the same place you found the download link (or a place that may be controlled by the same entity), that seems precisely as good as HTTPS.
So long as the secret key was not compromised, then the signature file also just doesn't matter - if it's compromised, the validation fails. One of the beauties of asymmetric encryption, making GPG worth learning about.
I think this really only applies for signatures you can trust. A frightening number of keys used to sign software are not signed by anyone, so they're effectively the equivalent of a self signed certificate.
I've also found some projects where the key used to sign the software isn't even consistent between releases, so you don't even have the (minimal) protection offered by checking the signatures against "known good" builds.
> A frightening number of keys used to sign software are not signed by anyone, so they're effectively the equivalent of a self signed certificate.
I wonder how hard would it be to socially engineer yourself into trust chain. I haven't read GPG manuals, but I'd be surprised if there were strict protocols followed by everyone when signing others' keys. Most people probably don't or can't insure that there is no mitm when signing keys and can't reliably verify that government id papers aren't forgeries so likely reliable chains of trusts exists only between people that spend large quantities of time together and exchange fingerprints over secure channel.
What could https possibly defend against here? Packages and other software needs to be secure at rest, not in transit. That much was learnt in the 90s. Nobody is going to target you with a mitm attack to inject a false image. Mirrors are the weakest link.
There are mentions of signatures but that these are "too hard". I looked at the Debian cdimage download and I end up in a directory with iso images and gpg signatures, so they're hardly invisible. There should be better instructions how to actually verify them, but inconstructive rants accomplish nothing.
But the watchmen can still see you connect to the IP address of yourfavoritelinux.org or its mirror. And then they can see you transfer approximately a distro image sized chunk of data. Perhaps you just downloaded your favorite linux distro?
I argue that the privacy provided is minimal, and for real privacy, you'll have to find something like tor (not an endorsement of it) or alternative, anonymous channels...
As for authentication, yes, it is quite minimal.
So HTTPS doesn't solve any problem well (meanwhile introducing some of its own problems). The better solutions to these problems make HTTPS wholly unnecessary.
I find the fixation on HTTPS bizarre, even concerning. Would the author have written this piece if all distros ticked all the three HTTPS boxes? Would he then no longer consider the state of things sad? That would be dangerous. That would be alarming. I hate the "false sense of security" argument that people apply to just about anything these days.. but this would be it.
What problems does HTTPS introduce (besides a potential for a false sense of security)? "Better solutions" (excluding the anonymity aspect) such as GPG signatures still require that you trust the key fingerprint used to sign the hash. That's not necessarily any more trustworthy than an HTTPS certificate, especially for someone who hasn't downloaded the ISO before.
"Would the author have written this piece if all distros ticked all the three HTTPS boxes?"
Most likely, as three of the criteria listed have nothing to do with HTTPS ("Checksum available", "GPG signature available", and "Verification instructions clear and easy to find").
I find the anti-HTTPS fixation equally bizarre. There are lots of approximately image-sized files one might download, so simply knowing that "IP X transferred 700MB of data from IP Y" is not the same as knowing that "IP X downloaded CentOS from IP Y, therefore target IP X with CentOS-specific attacks".
Nobody is anti-https here. The point is that it does doesn't protect against software distribution integrity (especially not when mirrors and CDNs are used). Pretending that security would improve with https risks making the problem worse, not better. What's needed is better instructions how to verify integrity included with the installation instructions.
This table says that Arch downloads aren’t over HTTPS, but the preferred way to get them is through a torrent, which is served (both the magnet link and the file) over HTTPS. It also means checksum verification instructions are unnecessary.
Assuming you trust your torrent client to verify file integrity/sums correctly, you'd probably still want to compare the author's checksum to the one on the torrent providers side at least
What do you mean “on the torrent provider’s side”? They’re all on the same server, and the magnet link and hash digests are even part of the same page.
If the source server is compromised then nothing can help you. All source links can be changed to something malicious and all verification methods can be different to match the ones of the bad file. If the source server is compromised there is no way to accurately verify the file's source (unless using verified PGP signatures which you've already vetted).
That's my point. Why go to the trouble of securing the transport layer if you're both NOT using PGP AND assuming with no proof that the server isn't compromised? I mean sure "security all the things" pays my ramen but at some point youve gotta wonder if you wouldn't be better off securing a trusted signature transmission method and comparing your insecure downloads to those provably correct signatures.
I'm not complaining, in the end clients assuming the server is uncompromised "because otherwise we'd be boned" and relying on transport security on top of that has secured me most of my work this past year... :)
Yes. If you assume the server isn’t secure, there’s no point in any of the other things except the PGP signature, the keys corresponding to which I wouldn’t be able to get anywhere without making some other assumption of security.
More like: The sad state of security "journalism".
Author doesn't have a clue what they're writing about.
Packages are signed with strong hashes. Their signatures verified in lists that are themselves signed by trusted keys. Images have HTTPS-verifiable, even out-of-band if you have any friends.
To say that this is in any way insecure because package transit isn't done over an encrypted link is lunacy. A minor, potential privacy issue maybe but if you're that bothered, mirror the whole repo.
"To say that this is in any way insecure because package transit isn't done over an encrypted link is lunacy."
The author was referring specifically to the download page itself. As they correctly point out, the checksums and keys themselves can be modified if the page isn't served securely.
As for 'trusted keys', that doesn't help someone downloading the ISO for the first time, who hasn't previously verified a download from that site (how do they know if the key fingerprint is the correct one?)
Me too (in part, though I missed the word "hash"). Natural collisions exist but it's bloody hard work to force a collision on a modified 800MB binary file.
That's well before you consider the group security of torrents (hashed chunks, optional SSL on tracker, etc).
It's easier to distract somebody and get physical access to their computer.
I just went to download the Ubuntu ISO. Everything was over HTTP, and I was not instructed to use or even offered any gpg signatures. I didn't see anything about hashes (which would need to be signed or offered over HTTPS to mean anything).
> Verify your download - If you want to verify the data integrity and authenticity of your Ubuntu download, follow our guide. Learn how to verify [2] ›
Yes, this could be more prominent. Yes, this download could be offered over SSL. Yes, ubuntu.com should definitely force-on SSL (rather than force-off). But these don't equate to a process that is impossible to securely verify. You can.
The SHA and MD5 checksums are both GPG-signed [3].
It's over HTTPs, and mentions both the short finger prints (0xFBB75451 and 0xEFE21092) as well as the full finger prints (C598 6B4F 1257 FFA8 6632 CBA7 4618 1433 FBB7 5451 and 8439 38DF 228D 22F7 B374 2BC0 D94A A3F0 EFE2 1092).
Incredibly, there does not appear to be any way whatsoever to securely verify downloads from respected openSUSE.
That seems not only incredible, but plain false. OpenSUSE offers PGP-signed checksum files prominently with the images. It also provides the signing key's fingerprint over HTTPS.
When choosing the regular releases you also get some verification instructions. This is not true when picking the Tumbleweed rolling-release distribution. In either case, though, the checksum files are signed.
Canonical in particular makes it very difficult to download images over HTTPS. For Ubuntu 16.04, I spent a relatively large amount of time trying to figure out the best way to download this image over HTTPS: After going through multiple mirrors, I eventually found a reputable mirror that offered secure downloads.
Seeing that there is no way for me to verify the authenticity of the signing keys (short of visiting canonical in person), every bit of security helps.
This is so ironic considering Mark Shuttleworth became a millionaire by starting and selling a certificate authority. Ubuntu is literally funded by the early success of HTTPS yet they don't use it.
It's worse: they don't have the updater working properly either. I switched to Ubuntu after the security issues with Mint since I didn't want to re-learn all the grunt stuff associated with Fedora or whatever. Not yet anyway. A while in, I find it won't update the software because /boot or something is out of space. I figure whatever causes that should be automatically prevented by Ubuntu given it is in many other OS's.
Gonna have to once again Google around to fix the problem or start from scratch with new install or distro. Might just bite the bullet to learn Fedora given it consistently ranks higher in security metrics. Don't know about quality or UX experience, though.
So, distributions and updates have issues in Ubuntu. The very things you want to be painless & secure.
In default install. Every so often I click updater and there are updates for CVEs. Why didn't you ask me Ubuntu? Why did you let me run software with known public vulnerabilities longer than is necessary?? I'm also befuddled why it sometimes prompts for password and sometimes doesn't, and I can't insure that the prompt is that of updater so I have to drop in shell and use apt. Or that it will happily let processes with updated binaries run and not ask to restart them. Ubuntu is a joke, but then half other distros are or I can't evaluate the leadership satisfactorily to know if it's a joke (e.g. as I suspected, Mint turned out to be one as they managed to release hijacked isos twice in a row). </rant>
Great examples. Especially the password thing. I figured it just remembered it from prior use. Yet, there were times it didnt ask during somethimg critical. So, who knows...
>A while in, I find it won't update the software because /boot or something is out of space
The boot partition is small and Ubuntu doesn't clean out old kernels. You have to do it yourself.
sudo apt-get autoremove
This will remove an old kernel. There may be a better way, because I find if there are multiple old kernels I have to do this multiple times. I also found if I have to remove more than one, it's best to follow with a
sudo update-grub
I previously managed to hose things by removing multiple old kernel versions, seeing a warning about needing to do this, ignoring it, then rebooting. So now I just do it after any autoremove that tosses an old kernel.
This may not be the 100% correct magic ubuntu dance, but it is the one that seems to work for me.
> Don't know about quality or UX experience, though.
UX should be fine but Fedora uses RPM so might have a bigger risk to end up with broken or incompatible packages, not sure though maybe things improved lately.
RPM doesn't have any bigger risk than using dpkg. You shouldn't be using either manually (unless you really know what you're doing). Using dnf/zypper/yum on the RPM side and aptitude/apt-get/whatever on the debian side should prevent any of those types of risks.
"For each ISO, we offer a checksum file with the corresponding SHA256 sum. For extra security, you can use GPG to verify who signed those .sha256 files. It should be 22C0 7BA5 3417 8CD0 2EFE 22AA B88B 2FD4 3DBD C284."
I'm surprised more distros don't just offer you a .torrent file over https. After you get that from a trusted source, you can download the files/ISO/image from wherever (webseeds, random people on the Internet) and the torrent client will do all the checksumming for you automatically on the fly.
It's also easy, simple and cheap to maintain while already being popular enough among your target audience. Certainly more people know how to run a torrent download than how to check GPG/PGP signatures or even would run a regular checksum.
It's misconstruing the problem as a primarily mitm threat. Considering the different methods of tampering with your download, I'd be more worried about server side compromises rather than otw
That doesn't mean we shouldn't mitigate MITM. Using either gpg or tls without the other makes the security of the system weaker than it needs to be. Gpg key authenticity can't be practically verified by end users.
The table in the link isn't alarmist: it's alarming. Secure distribution... at least an effort... was a requirement in INFOSEC since the Orange Book in 90's. FOSS proponents pushed Linux distro's, and still do, for the foundation of security-oriented projects. This is 2016. They still don't have trustworthy distribution under control except Fedora apparently. It's worth noting.
Anyone wanting to build on this should apply same methodology to major BSD's to see how they compare.
I don't think the table really covers the everything quite well enough. In reality it doesn't really matter if the download is over HTTP or HTTPS as long as you can safely verify that the file you have is indeed the correct file.
For example, Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now. Even if one has provided instructions for doing so it's still going to require that the end user cares about checking the validity of the files.
"Arch has HTTP downloads but the download page provides the MD5SUM, SHA1SUM, and PGP signature for verification that the files are correct. I just don't really see this as that big of an issue right now."
One of the points in that and article jacquesm linked is that checksum verification still requires trusting the transport. Otherwise, you get fake binary plus fake checksum that then look safe but were for malicious app. There's just an extra thing to change for attacker. No work at all given what was already put in to get to that point.
So, trustworthy transport of binary and/or checksum is necessary. The checksum should still be there even if binary is sent safely, though, to verify no corruption of binary happened due to transmission or storage faults.
The checksums and PGP signature are on the HTTPS page which links to all the downloads. You have to trust that page from the start no matter what (or establish the PGP signature trust from other ways, which is quite possible just far more involved) because that's the source of all downloads and anything there could be faked from mirror links to checksums to PGP signature (assuming no trust chain is actually established by the user).
My initial point is that no matter the solutions offered, the user has to care about checking. Forcing HTTPS transport for the download isn't really going to make it any more secure because it's still possible the file is illegitimate and you should be testing the signatures.
tl;dr: Arch's downloads are over HTTP, the checksums and signature are over HTTPS and on the official download page.
I don't know fedora, but when I tried to switch I found the following blocking issue. Fedora has packages missing that you can get in Ubuntu (irc it was vlc for me). There is RPM Fusion but it doesn't have reliable method of verifying repo keys - they send instructions only over http and have only selfsigs on keys. As this has been going on for years and without bothering anyone I can't trust them even if they fix it sometime in the future.
I've gotten passed this with the help of two reasons, the first is because ISO images (even for minimal installs...) are huge and HTTPS'ing it all would be an expense from the mirror's end (hopefully with better tech this'll become an after-thought...) and secondly I've learned enough to generate my own checksums to copy and paste across search engines (in Google and with quotes, search strictly for your checksum and look for multiple sources sharing the same context regarding your download/image.)
I've had the luck finding and verifying the majority of what I'd concern myself with. But what really frustrates me is downloading something (verified and all...) and then record its traffic downloading its updates via HTTP. I don't know if it's verifying its own downloads but I simply wish applications were more transparent or that applications had no shame in throwing up a screen providing the checksums of its downloads (well maybe for the users like me who have the time to put towards verifying every thing coming in.)
So I love Notepad++, but I hate how its plugin manager (last time I checked...) downloads the majority of, if not all, its plugins from sourceforge and over HTTP. Windows UAC will pop up saying the newly selected plugins want to make changes to my computer - no, I stop there. If I can, then I'll download the plugin from its developer's GitHub and prepare it to use for Notepad++ myself. The plugin manager could be verifying packages, the packages could be hosted on something other than sourceforge, or whatever else. This is a rant over things I've already built habits and routines around.
Worth noting that a GPG signature is of limited (though not zero) use if the signing key doesn't have any signatures. In this respect, Debian contrasted favourably with Fedora the last time I looked.
True, but for both of them you already might be able to get the proper key through a trusted channel. Fedora has the keyrings for at least Arch, Debian and Ubuntu (besides its own ones, naturally) in its RPM repos, so Fedora users can get them in a secure manner. Debian also has at least the Ubuntu keys included in the repos.
Fedora's own key is also available over HTTPS so you get at least some assurance when bootstrapping.
A followup on package update delivery would be quite interesting. While the updates are (probably) universally signed to prevent tampering, delivering them in the clear is still an infoleak -- attackers can monitor the update traffic to identify packages that a target has installed, including the exact version, revealing which packages are fully patched and which are still vulnerable.
It's not a big information leak though. Once you know what the system is (which is usually trivial), how many versions do you usually have to choose from? 2-3? At that point you can just try to exploit for each version. Why do you think knowing the version beforehand helps?
I agree it's only a modest infoleak. Depending on the nature of the exploit you may not have multiple attempts. Consider also that one can block updates by serving the client stale update lists/packages. The client sees "no updates available" and thus the attacker can extend a window of vulnerability. Using TLS on the update delivery mirrors raises the bar.
I usually just hash the ISO and plug the hash into Google to see who else agrees with it. I figure that if someone has the ability to fuck with both my (HTTPS) Google results and my ISO downloads, I'm probably already too compromised for any third-party security infrastructure to help.
It uses sha-1 for each piece of content. Although sha-1 considered insecure, I'm not sure of practical possibility to introduce collisions while injecting working malware. Should be very hard.
"Official releases of Debian CDs come with signed checksum files; look for them alongside the images in the iso-cd, jigdo-dvd, iso-hybrid etc. directories." No directory or direct links are provided. Verification instructions are not linked to from the download page.
I do:
- https://www.debian.org/
- https://www.debian.org/CD/
- https://www.debian.org/CD/http-ftp/
- https://www.debian.org/CD/http-ftp/#stable
- http://cdimage.debian.org/debian-cd/8.5.0/amd64/iso-cd/
And here, along the images, there are difficult to miss (and GPG-signed) SHA256SUMS and SHA512SUMS files. Moreover, the last page clearly links the verification instructions in the "How can I verify my download is correct and exactly what has been created by Debian?" section.