So, for me the trust chain for the Fedora installation DVD is:
- The trust chain root is my current browser (a recent enough version of Firefox);
- The browser trusts the CAs in its certificate store (the built-in CA certificates from Mozilla, plus the ICP-Brasil CA certificates);
- One of these CAs verifies the certificates for the fedoraproject.org pages;
- From these pages, I download a set of public GPG keys, and if I want I can verify their fingerprints;
- The torrent for the installation DVD has the DVD image and a checksum file. I use GnuPG to verify the signature on the checksum file, and check the page to confirm that it was signed with the correct key;
- Finally, I verify the SHA256 of the DVD image and confirm that it matches the value found in the checksum file.
I don't know how I would do it for OpenBSD. The www.openbsd.org page doesn't seem to be available over TLS, so I can't use the CAs trusted by my browser to bootstrap the trust chain. If I had OpenBSD 5.5 installed, I could use it as the root of the trust chain (as explained at the link you posted), but unfortunately I don't have it installed anywhere, so that trust path doesn't work for me.
If I had an OpenBSD 5.6 ISO in hand right now, what could I do to authenticate it? (Assume I have a recent Linux or BSD system to start with.)
The official way of doing this is to buy the CD set in which the code and keys are sent via different channels. You buy the CD set and it is mailed to you. You then verify that against the key on the web site.
If the verification fails, either the CD set or the key is compromised.
I really wouldn't trust a CA or shared PKI to do this to be honest as that means you have to trust three or more parties rather than just two.
Networks are easy to attack if you have control over the ISP. Mail can be easily replaced by one single person monitoring someone's mail.
A company where employees get their mail at work and only access the net from work could do both easily.
I don't have resources for something like this, but doing this isn't as difficult as it might seem. A big enough adversary with enough resources could compromise everything used in security sensitive environments.
I wanted to know if anything changed in how OpenBSD can be installed securely. It is easier to obtain other operating systems securely. They are less secure, but the authenticity of the iso files can be verified via signatures.
This uncertainty has stopped me from using OpenBSD in the past. I have the same questions now.
This is a question about obtaining an iso file to install OpenBSD knowing it's what the developers sent out, just like checking a sha256 signature for other operating systems when downloading. It's not a question about using it in a government agency.
Thanks for the replies. You probably have more useful things to do than discuss this.
If it is so easy to attack, then you already lost the game unless you've pinned the fedoraproject certs. The CA model has been demonstrated broken long ago.
So would you rather trust that model, or just obtain the OpenBSD key for yourself via multiple different channels, from multiple sources? The key, by the way, is all over the place. You start with the official site, but you can cross-check against all the CVS mirrors, and you can check all mailing list archives which contain the key in the release announcement.
I would dare say that is heck of a lot better than simply trusting your CAs, if you are indeed so easily attacked.
Without TLS and having control of the network, it doesn't matter how many channels over the network you use; it's simple to MITM everything and search-and-replace all text matching the key with your forged key (in fact, many networks already MITM all non-TLS HTTP traffic through a "transparent proxy").
With TLS, even with the imperfect CA model, it's much harder. It might have been "demonstrated broken", but can you get a certificate for "fedoraproject.org"? It's not that easy. Add to that the Certificate Patrol extension, which warns the user quite noisily when a certificate is signed by a different CA (and shows the user the old and new CA).
With mailing the CDs, as suggested several posts upthread, it also gets harder; now the attacker has to MITM two things (the network and intercept the physical disks). If you add TLS, it gets even harder (three things: MITM the network, intercept the physical disks, and obtain a valid forged certificate).
So, trusting the CAs is better than getting the key via multiple unencrypted channels through the same network. Trusting the CAs plus getting the key via multiple channels is even better. The methods are not exclusive, and "multiple channels" is already common in practice (in my Fedora example, the DVD image is obtained via bittorrent, while the key is obtained via TLS, and they have to match).
I think you may have a little too much faith in the gnupg binaries and ca list and whatnot you have now. Remember, at some point you got them over the same untrusted channels.
Yeah, but the gnupg binaries and CA list and browser executables and whatnot were validated by the package manager, which came from a install disk validated by older gnupg binaries and CA lists and browser executables and so on...
In the end, the trust chain stretches to files downloaded using Netscape 2 via dialup sometime in the last millennium.
Yeah, the chain might have been broken a few times in the meanwhile. Still, it's better to chain from what you have than to start from scratch every time. The more you do it, the longer the chain stretches. And it takes just one person with an unbroken chain from before the attacker has even been born to sound the alarm.
