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 The OpenBSD people do not seem to maintain a public HTTPS web site with a copy of the 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) |
||||
|
|
|
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. |
|||
|
|
|
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. :) |
|||||
|