2015-07-31 0:17 GMT+03:00 Stuart Henderson <s...@spacehopper.org>: > On 2015-07-30, Vadim Zhukov <persg...@gmail.com> wrote: >> 2015-07-30 20:16 GMT+03:00 Stuart Henderson <s...@spacehopper.org>: >>> On 2015-07-30, Ted Unangst <t...@tedunangst.com> wrote: >>>> Michael McConville wrote: >>>>> > Another meat could be, why you're using self-signed certificates? >>>>> > Given the plethora of options for getting free (valid) certificates. >>>>> >>>>> He mentioned in his original email that it's a requirement where he >>>>> works. That's common, from what I hear, although probably not the >>>>> safest. >>>> >>>> I would consider a cert signed by somebody I actually trust (me) safer than >>>> delegating that trust to 300 strangers. >>> >>> I think cert.pem should move to the etc set, so you can remove >>> CAs from the file (as well as add new ones) without risk of those >>> changes getting reverted. >>> >>> Downside: CA changes will then only take effect after running >>> sysmerge. Is that a problem? >> >> I think it is. This is the same as with /etc/examples: less stuff to >> merge, less errors to happen. > > cert.pem is pretty much a required file, we can't just move it to examples/. > For people who don't touch it, it's a simple no-touch sysmerge update. > For people who do, having sysmerge ask about merging it is a lot safer > than just overwriting.
No, I didn't want to move /etc/ssl/cert.pem it to /etc/examples. I think that its current contents could be provided in other way... >> I'd ask another question: why can't software use /etc/ssl/myown.pem, >> or /etc/ssl/*.pem, ever, instead of /etc/ssl/cert.pem? This will make >> "trust" and "untrust" operations as simple as possible. Noone in >> healthy mind would place junk in /etc/ssl anyway, right? > > Some software allows you to set a different certificate file; other > software doesn't. Patching everything in ports that verifies SSL certs > to allow the user to specify an alternative file would just be insane. Hm-m, I always tried to live in a separate room with SSL beasts. Now I realize that I saved a lot of nerves myself, and as a result I'm living in a pink pony world. Thanks for getting back to the ground. I thought that there was some "default" in OpenSSL (and its decendants) that programs tends to use. Now I realize there is no such place. Okay, this variant gets busted. > And of course then there's no single way to tell programs to use the > alternative file; "ftp -S cafile=/path/to/cert.pem", > "env SSL_CERT_FILE=/path/to/cert.pem lynx" > >> Or we may ship /etc/ssl/base.pem in base tgz, and install >> /etc/ssl/cert.pem -> base.pem at installation time. This way things >> will work by default, and if you need to have your own trust path, you >> just change symlink. What do you think? > > That doesn't really help. One common scenario is wanting to add a > single CA to the standard file, but otherwise pick up updates (e.g. with > sysmerge), this method doesn't allow that. Well, I see four scenarios: 1. Using the defaults supplied with OpenBSD only. Typical for home/personal use. 2. Use the defaults supplied with OpenBSD, and one or more additional CAs. Typical for corporate use. 3. Use personal set of CAs. Usually means either white-, or blacklisting entries from "base" certs pack. After more thinking I see that symlink idea is not good. But we can do some other thing: 1. Have "base" certs installed into /etc/examples/certs.pem. 2. Additional certs, if any, should go into /etc/ssl/local.pem. 3. Have sysmerge handle certs specially: comparing not (old) /etc/examples/cert.pem with /etc/ssl/cert.pem, but /etc/examples/cert.pem+/etc/ssl/local.pem vs. /etc/ssl/cert.pem. In case they do match, sysmerge would regenerate /etc/ssl/cert.pem by concatentaing (new) /etc/examples/cert.pem and /etc/ssl/local.pem. What do you think? -- WBR, Vadim Zhukov
