12

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?

AviD
  • 72,138
  • 22
  • 136
  • 218
LanceBaynes
  • 6,149
  • 11
  • 60
  • 91
  • Calling OpenBSD the "securest os on the planet" is a pretty S&A phrase. Saying that the devs put their biggest focus on security might be more accurate without being S&A. – Scott Pack May 28 '11 at 12:53
  • I asked a similar question about OpenSSH (part of OpenBSD) to their mailing list and the gist of the answer is that PKI is hard and "surely you know that x.509 is well-know as a shambles....". – Siyuan Ren Oct 13 '14 at 04:31

9 Answers9

13

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.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    Getting an ISO and verifying it with a hash, when both are received via un-signed communications, is *not* "as good as getting the whole file through HTTPS" for a couple of reasons depending on your security concerns. One of them has come up twice already on this site. – Iszi May 28 '11 at 17:34
  • Link to aforementioned question: http://security.stackexchange.com/q/1687/953 Plus, there's been an exact duplicate recently. – Iszi May 28 '11 at 18:15
  • 2
    Wow - that's shocking - I also see no hint of a PGP signature or other reliable way of providing confidence in e.g. the recent OpenBSD 4.9 release - http://www.openbsd.org/49.html – nealmcb May 28 '11 at 18:33
11

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://mirror.ece.vt.edu/pub/OpenBSD/4.9/

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.

john
  • 10,968
  • 1
  • 36
  • 43
  • 1
    OBSD is stated as the worlds securest OS. Why are they doing such a thing to not to give downloads over HTTPS to ensure that I have really downloaded the right ISO image and to ensure that I really have the right checksum of it? – LanceBaynes May 28 '11 at 11:47
  • 3
    This is exactly what is done by providing you with a checksum to verify against. – john May 28 '11 at 11:49
  • This mirrors https encryption and certificate only verify that this mirror is who they say they are. Unless they are a wholly owned subsidiary of open bsd (lol) then the https traffic doesn't add any security – Andrew Russell May 28 '11 at 13:24
  • 1
    I agree with you. I was merely answering the question, about not having a https mirror to download the files, I didn't imply everything is secure - for example how did VirginiaTech gets the isos. – john May 28 '11 at 13:32
  • 1
    @AndrewRussell What about a MITM attack? Perhaps I have a malicious ISP and they detect it's the OpenBSD ISO and change some bits. Wouldn't HTTPS protect against that? – Ben Aug 19 '14 at 15:17
  • @ben as above you only need to get the checksum securely, from a verified correct source, and check against the iso which verifies it is correct (as published bsd). – Andrew Russell Aug 19 '14 at 21:39
7

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)

Andrew Russell
  • 3,633
  • 1
  • 20
  • 29
5

The issue is now addressed in the paper signify: Securing OpenBSD From Us To You by Ted Unangst (BSDCan, 2015).

In summary:

  • 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 signify.

    • 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.

My take:

To verify the artifact with signify, one must obtain a trusted implementation of 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 signify.

Andy Lee
  • 191
  • 2
  • 5
3

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. :)

Lizbeth
  • 757
  • 6
  • 14
  • y, that's a great thing, now I only want to know that fetching a GPG key can be compromised :P -> http://security.stackexchange.com/questions/4161/shouldnt-gpg-key-fetching-use-a-secure-connection – LanceBaynes May 29 '11 at 17:59
  • small nitpick - the SHA256 takes care of integrity, not authentication (a file isnt who anything... its a what). The GPG signing takes care of authenticity, that the hash is the *correct* hash (i.e. created by the correct entity). – AviD Jun 05 '11 at 11:35
  • "sign the hash with a GPG key" ... and where does one obtain the signed hashes from? Release engineers do not seem to publish these. Instead they use `signify` (which AFAICT can't benefit from the PGP WOT). So then we also have the problem of how to identify the correct key (unless each user meets a release engineer in person) – Jonathan Cross Sep 21 '18 at 15:06
  • FYI: Users can now verify OpenBSD's signify release key using the PGP Web Of Trust: https://unix.stackexchange.com/a/477232/100248 – Jonathan Cross Nov 02 '18 at 23:19
1

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.

Antonius Bloch
  • 507
  • 2
  • 9
1

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.

ali
  • 11
  • 1
0

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!

https://www.grc.com/fingerprints.htm

https://www.openbsd.org

Take this secure server in Canada (Beauharnois, QC) for download the .iso

https://openbsd.delfic.org/pub/OpenBSD/

Vim
  • 1
  • 3
0

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.