OpenBSD claims to be highly secure. So why doesn't it allow downloading the release iso's over HTTPS? Or I'm missing something? Can someone please explain this to me?
First of all, OpenBSD is really just on a server in Canada, where the development takes place, through CVS. People replicate the tree by connecting using SSH there etc. When releases are made, isos are created and mirrors replicate them. I imagine they get the files using a secure way, but can't know for sure. Then you have a list of mirrors to download from.
I checked and one of the mirrors supports HTTPS (it is a server located at the Electrical Engineering department of VirginiaTech university)
HTTPS is not really needed for downloading the ISOs. In each directory, in all mirrors, there is a file called SHA256 which contains the SHA256 checksum of each file in the directory. This is the one file you should really get in a secure manner - the files will get verified against that later. Since there are multiple mirrors, if one is compromised, you can check the checksum file on another mirror.
There is a file called
SHA256 which contains the checksums. Technically you only need that file to be transmitted securely; you could get the ISO through any mean, and just verify the checksum. This would be as good as getting the whole file through HTTPS.
The OpenBSD people do not seem to maintain a public HTTPS web site with a copy of the
SHA256 file. Also, HTTPS is as secure as the X.509 PKI model allows for, and OpenBSD folks seem to be somewhat queasy with regards to X.509 and the preinstalled CA in Web browsers (which is quite understandable); they seem to prefer the OpenPGP model. I think that in older days, the announcement for a new OpenBSD release was a PGP-signed email (sent to various places, including Usenet), which contained the digest for the main ISO -- thus realizing full ISO integrity relatively to a PGP public key. But I am not sure they are still doing that.
Otherwise you can order a physical, tangible CD set (or DVD). They are not expensive.
I agree, they should make available a way to securely authenticate the iso's.
They should provide an authenticated mechanism (to https://www.openbsd.org) to retrieve the sha hashes instead of leaving the hashes sitting beside the just-as-easily-compromised iso file.
But in the absence of that you can, download, wait and verify that there isn't a security stink before using the relevant iso. Checking the sha's are the same on all mirrored sites. I would think that 1 week would be enough.
(I see @thomas Pornin has just said most of what I said above)
The issue is now addressed in the paper signify: Securing OpenBSD From Us To You by Ted Unangst (BSDCan, 2015).
Requiring mirrors to use HTTPS, and any other reliance on HTTPS, was rejected.
- As noted by other answers here, securing only the connection between users and mirrors does not secure the transit of artifacts from developers to users. (However, in theory one could distribute just the SHA256 file via HTTPS directly from openbsd.org.)
- OpenBSD developers did not trust Certificate Authorities enough.
- TLS was considered too complex.
PGP and GPG, considered as alternatives, were also rejected.
- Considered too complex.
Decision was to develop
- From its manual, it is meant to "cryptographically sign and verify files".
- Signify was designed to be easy to audit.
- Trust in keys is developed by "wide dispersion":
Wide dispersion makes it harder and harder to intercept all the ways you may get the key and increases the risk of detection should anybody try some funny business.
To verify the artifact with
signify, one must obtain a trusted implementation
signify to run. This could be satisfied by already having a trusted,
recent-enough installation of OpenBSD. Otherwise one can try to obtain a port
of signify, such as signify-osx, and audit the code. Next one needs to find
the public keys. For reference, they are contained in
/etc/signify in the
OpenBSD source tree. One could try to obtain it from as many sources as
possible. However, if you are using "wide dispersion" as described in the
Unangst paper to develop trust in the public key, then you may as well use
"wide dispersion" to develop trust in the SHA256 hash, and obtain your first
trusted OpenBSD installation that way. (Unless you find the public keys are
more widely dispersed.) Thereafter you can use
I wanted to say that maintaining an SSL site is a higher cost than HTTP especially when you have that many users. It costs more cycles of CPU, it costs more to maintain the certificates, and because SSL cares which order the packets come in, there is a higher bandwidth cost.
In this situation, the user downloading the ISO is concerned that the file has not been tampered with (either during transmission or while it's stored on the site), not necessarily that sensitive information is going to be disclosed during the transaction as SSL/TLS would help you with.
So in regards to the 3 A's of Security, this one would be authentication; verifying that the file is who it is which as @thomas pornin pointed out is taken care of with a SHA256 hash of the file that you download separate. Now you're going to say that the SHA256 hash could be manipulated to match the hash of a compromised ISO, and that's why you need sign the hash with a GPG key.
So you don't need SSL because you verify the hash with the GPG key, the hash verifies the ISO, if all that fits together you've successfully verified the integrity of that file.
I like to also point out that SSL != security but that's another subject. :)
I think there is a wide gap between "absolute" security and "good enough" security. Is SSL encryption worth the compute overhead on all of OpenBSD's mirrors? I don't think so. The chance that someone is going to hijack your http download session and patch your iso and then update the checksum is pretty low.
A more likely scenario is that the files get patched before you download. SSL isn't going to help in that case. That's where checksums come in.
Every OpenBSD user have a file located at /etc/signify/ directory to check downloaded installation files for next OpenBSD version (ex. 5.6 -> 5.7 upgrading). Also, each directory of OpenBSD site (and mirrors) have a file named SHA256.sig. You may read signify(1) manpage to find out how to verify a directory containing SHA256.sig and files inside that directory.
These instructions are useful only for OpenBSD users. At this moment I have no general secure instructions to download OpenBSD.
When someone does not want to be tracked what he downloaded, the best way how to get the file at the moment is in my opinion Bittorrent. Bittorrent supports encryption and one can force it to allow only encrypted streams, the ISP or anyone else in the middle has no chance to find out which parts where downloaded from where. And the torrent hash file is a checksum in itself, one would only need to somehow cryptographically sign this, so that one can verify that that torrent file is authentic. Nowadays you do not even need to put the torrent file online, as it can be downloaded through magnet. One would then only need to hide the communication with the tracker, maybe there is support for SSL trackers, but this can already be done through proxying it.
I think OpenBSD was the fist one to get rid of FTP mirrors, they now only want HTTP serving out the files. And HTTP is the only choice if you do not have your own (NATed) IP address, or you are behind a proxy, so that you can not do bittorrent.
Of course, OpenBSD is not distributed by bittorrent officially yet, but NetBSD for example does it, FreeBSD did it, but stopped, no idea why. I was thinking about this problem of mirrors as well, but I am not that paranoid that I would think someone is tampering with the files, but you can never know.
Whether it comes from the original distributor, you know only when you're checking with signify.
By calculating the image's checksum on your own computer and comparing it to the original checksum, you can verify the image has not been corrupted, during your download. More it says not.
Secure browser connections can be intercepted and decrypted by authorities who spoof the authentic site's certificate. But the authentic site's fingerprint CANNOT be duplicated!
Take this secure server in Canada (Beauharnois, QC) for download the .iso