I'm using ACME and Let's Encrypt since it became available, and quite
happy that it is available, which is a large improvement over the
scammy and manually operated CAs. Yet the ACME clients were awkward,
and they stay that way still: the primary one wanted to run as root,
and to edit configurations of other services; for some reason on
CentOS a man page wasn't included, and on Debian it's just the --help
output (which, for some reason, certbot prints with a perceivable
delay). Everything is roughly the same still, but at least with some
manual hacks it can run as an unprivileged user. And then there are
alternative clients, which were/are incomplete and/or broken, leading
to even more awkwardness.
The only time I saw a person actually using certbot's nginx
configuration capability (and running it as root, even though it's not
necessary to edit configuration) was when they've also installed it on
Debian from an Ubuntu PPA repository (while it was available from
system repositories). I think it was a person who wanted to use Docker
to deploy static files on a single server. I found it all to be quite
fitting: "heavy-handed" describes both certbot's and that person's
behaviours well. Actually there's quite a few people who like to do
all the things as root, and generally to drop even basic security and
safety measures in favour of convenience.
The alternatives that I'm aware of and that are commonly available in
system repositories don't seem to be much better though: I don't
recall any that support RFC 2136 (dynamic DNS, for ACME's DNS
challenge) on their own (without custom/external software), while it
seems to me like the most sensible thing to support; certbot supports
it with a plugin that is available from both CentOS and Debian
repositories. Some clients are written as shell scripts, which made
sense when it was new (ease of deployment, minimal dependencies), but
doesn't make much sense now, when they are included into system
repositories.
I'd prefer a nice small ACME client, with good system integration,
documentation, possibly only supporting the DNS challenge and RFC
2136, well-maintained, and included into system repositories. Upon
looking around and not finding any, it crossed my mind to write one,
so I went to check the ACME protocol specification (RFC 8555) more
thoroughly. More awkwardness awaited there.
The protocol's task seems simple: a client should be able to request
and revoke certificates, proving control over the domain(s) it is for,
and there already are standard CSR formats. ACME solves it by, among
other things:
- Adding account registration and authentication. With acceptance of
ToS, which is probably the reason for that.
- Including a directory service to provide URLs for various standard
operations. That actually may include more (per-command) ToS, and
assists with using external accounts (which are also supported by
the protocol).
- Including "url" parameter into JSON payloads, apparently to help
ACME servers with sorting it out. And generally aiming to use common
nowadays web-related technologies; it reads a bit like an ad hoc web
service's documentation.
- Implementing something akin to TLS-over-JSON-over-HTTP-over-TLS:
handling replay attacks and authentication in a custom protocol
while TLS is capable of that. Apparently it's assumed that a CA may
accept connections from a third-party MitM service that would handle
TLS connections on its behalf.
- Extensively using base-64 encoding to encode binary data that should
be included in a human-readable serialization format (JSON), inside
human-readable network protocol packets (HTTP), both of which were
chosen mostly to transfer that binary data. With base-64-encoded
strings inside base-64-encoded strings in some cases.
The feeling after reading it is similar to the one I had after using
certbot and reading its documentation: it does the job, and it's not
too bad overall if you take into account the target audience and other
not-quite-technical aspects. But it's still pretty awkward, so I'm not
happy to use it.
I've ranted in an XMPP conference about it yesterday, and was reminded
that TLS is an awkward/hacky way to achieve transport security in the
first place. Indeed, IPsec is a generally nicer alternative to this.
It's quite far from a viable option to rely on right now, but is worth
looking forward to, and certbot/ACME then look more like temporary
hacks until we are there.
IPsec can rely on DNS (with DNSSEC), using either IPSECKEY (RFC 4025)
or DANE's IPSECA (there's just a draft), and employ at least
opportunistic encryption (RFC 4322). TLS can do a similar thing, with
DANE's TLSA (RFC 6698), without relying on CAs; though I doubt that
major web browsers and other potential clients currently support it.
Though IPsec has its own problems, and criticized for being overly
complex. But there is some hope for neat setups for secure networking
in the future, and one can already start adopting some aspects of it.
It may be particularly nice for protocols like Gopher and telnet,
providing some security without changing them.
