> I dislike the idea.
>
> For one, it does not stop a MITM by itself.
>
> In addition, enforced encryption makes it hard to cache and/or use
> proper http proxies with the site.
>
> Purely informative sites don't need TLS. The user can opt to use TLS
> if he thinks the content he needs to read is somehow sensitive, or
> configure his browser not to use the regular http version if he feels
> like doing that. A pure simple redirect does not add much to security
> unless the user takes extra steps - but if the user takes extra steps
> he does not need a redirect at all.
Huh, it seems obscured faces always come out of the woodwork to smash
using https whenever there's discussion about it.
Regarding letsencrypt, I use it because I'm cheap and lazy and have more
domains than patience. Unfortunately the client is horrifying. Here's
how I reconcile my cheapness--I figure others might have a better
solution than this, so please let me know.
(By the way, httpd(8) doesn't support SNI yet--what do you use a web
server? I found that apache2's chroot and https combo didn't pass the
"can I set this up in less than five minutes" sniff test--I ended up
using nginx.)
(1) download one of the many letsencrypt shell scripts (I couldn't find
any reasonable ones that didn't require bash in a five-minute search), e.g.,
https://github.com/lukas2511/letsencrypt.sh
(2) have a local no-login user that will do nothing but run the
aforementioned script in a cronjob, which in turn keeps the certificates
(owned by that user) up to date;
(2b) configure the user to have access to, say, /var/www/letsencrypt for
the "domain-check" phase and set that in WELLKNOWN, with your web server
alias /.well-known/acme-challenge to that directory, and have the script
keep the certs somewhere in the user's home;
(3) have a doas rule for copying certificate parts from that user's
certificate directory into, say, /etc/ssl/letsencrypt (owned by that
user); or have root do it instead;
(4) have a doas rule to reload the web server;
(5) have a cronjob (or script from a cronjob) for the dedicated user
that runs the letsencrypt script and, if it finishes with success, use
doas to copy the certificate parts out and reload the web server. I can
share mine if you'd like, but it's just that.
In the end, the /etc/ssl/letsencrypt (certificates) and
/var/www/letsencrypt (domain validation) directories are effectively
owned by the dedicated user, and I assume that they might be filled with
crap if the local account somehow gets pwned. Can anybody suggest how
to make sure that the certs aren't bogus across cronjob script runs?
Another step between the server reload and copy could check-or-reject to
make sure that the server doesn't try to load bogusly-crafted certs?
Ideally I wouldn't have the letsencrypt actually touch the private keys
at all, or run the web server reload, but directly or indirectly a
change in cert would need to trigger that, and that's at the mercy of
the script anyway. I just assume anything in those directories is toxic.
Best,
Kristaps
