letskencrypt / acme-client

A day or so ago they decided to promote letskencrypt (now renamed acme-client) into OpenBSD-current from being a port

I want to say up front that having any ACME implementations at all is definitely worth doing. It is _totally_ possible to argue that letskencrypt specifically is a good idea. It uses privilege separation which is a very OpenBSD feature, and it's been written by somebody who clearly really, really believes in taking security seriously.

But on the other hand, in focusing so very hard on the trees, letskencrypt in my opinion utterly fails to notice the forest. For example, letskencrypt privilege separates code that reads the private key from code that goes over the network. But if you're genuinely worried about bad guys stealing your private key then your ACME client needn't ever see it at all. Let's Encrypt expects to receive a CSR (proof of control of the private key), which can be generated by a separate piece of software or hardware, even air-gapped if you're crazy enough, and the private key is only needed by letskencrypt because it doesn't accept a separate CSR and instead generates its own.

Writing everything by hand with C (even going to so far as to use a miniature hand-rolled HTTP client implementation rather than one of the libraries that's known to do a good job of HTTP) seems like it reduces the attack surface. But that relies on the assumption that C isn't worse, or at least not _much_ worse than alternatives like Python for security problems. This assumption seems very dubious.

The insistence on doing the simplest thing, without considering what the Right Thing might be has already tripped up letskencrypt in practice. Let's Encrypt changed their subscriber agreement. Correct implementations noticed the changed agreement, and perhaps displayed it (or a URL for it) to their users, but most importantly (from the point of view of someone who wants the damn thing to work) they submitted back acceptance of the new terms. letskencrypt had hard-coded its response, which of course was now wrong. Did the author fix this with a bunch more code to correctly implement the protocol? Nah, they added a flag to substitute a provided answer so every OpenBSD sysadmin out there can end up maintaining a hack to override things each time the Ts&Cs change...

And in the end that shrunken attack surface also means letskencrypt can't solve a lot of the problems that the relatively heavyweight options like cerbot do. Don't actually have an HTTP server? Too bad, letskencrypt can't help you since it doesn't include that functionality. Want to use the TLS-SNI based validation, or the DNS validation instead of HTTP? Too bad again, letskencrypt will leave the crucial validation step for you to someone how complete by hand.

But it adheres well to OpenBSD policy, and that is evidently what really matters.