[ef4]

If you are running your own webserver even a static simple site has required maintenance. You need to keep the server and OS patched. So adding a letsencrypt cron job is not any worse than configuring something like Debian's unattended-upgrades.

But I don't think most site owners should be doing even that much. They should just pay for static hosting, which is cheap and ensures somebody else will keep the server, os, and cert all safe.

[1wheel]

I added https to my static site last year and it has been a huge waste of time.

ubuntu + nginx worked fine for years without much maintenance, but I've spent so much time reconfiguring things when something breaks (and it is really clear when something a renewal fails... thanks HSTS).

Things that used to be simple, like putting setting up a subdomain (need to get a new cert and reconfigure the cron job now) or pointing at a websocket (can't point directly at node since that's not secure, needs to pass through nginx now) consistently take hours to do now.

I mostly do data analysis and front end work; mucking around in nginx config files is something I would have been happy never experiencing. It sucks that it's harder to host your own website now.

https://pastebin.com/N2sbvULA

[kelnos]

I have nginx fronting around 15 different (very low traffic) websites (most static, a few python), all of which have Let's Encrypt certs. The required additions to the nginx conf were minimal and easy. Adding a new subdomain is trivial. Fetching the initial certificate from Let's Encrypt is a short, easy command line. And "sudo certbot renew; sudo /etc/init.d/nginx reload" in a cron job keeps the certs up to date (the "renew" command is smart enough to go through the list of certs you have and renew them all).

It's really hard to imagine it getting much easier.

[andrewaylett]

Try `certbot renew --post-hook "/etc/init.d/nginx reload`, which will only reload nginx if at least one certificate changed :).

[Retric]

You don't actually need to keep web servers serving static content patched. Simply close all other ports, run a minimal web server, and it's a tiny attack surface. Some of these have made it 20+ years with zero maintenance.

[robocat]

I use cloudflare for my static website so that https is seen by the browser even though I am serving http.

Advantages are that it is free and zero maintenance, however nation or network providers can intercept between cloudflare POP and my server. I'm ok with that for my situation.

[kelnos]

As a website visitor this has always bothered me. HTTPS used to mean that I had an encrypted path between my browser and the server actually serving the webpage. With Cloudflare allowing this weird hybrid mode, I can never actually know if the connection is secured all the way end to end.

[jacobparker]

cloudflare didn’t invent this or make it normal. It’s always been common to terminate https in front of your “actual” server and with re-encrypt to the “actual” server or (very common) ... don’t.

Cloudflare may have made it more common for the most basic kind of site (with their easy setup and free tier) but at the same time most of those sites probably didn’t use https anyway.

The reasons this has been done are performance (specialized hardware/separation of concerns) load balancers/firewalls needing to decrypt to route/enforce policy (that doesn’t need to imply termination but it often goes hand-in-hand) and protecting keys from your app server (think of it as like an HSM - if your app server gets compromised you probably don’t want the TLS private key to be leaked. Again you could reencrypt with a different key but often this hadn’t been done.)

The threats for last mile network fuckery (e.g. consumer ISP) are quite different then on the backend. Google has to worry about nation states messing with their networks and so they’ve had to reengineer end-to-end encryption within their network. As an end-user you just sort of need to accept that this isn’t within your ability to control or know.

[JetSpiegel]

Reverse proxy were usally not routed through the Internet, only a local network.

[jacobparker]

Sure but the GP made a much stronger claim that they previous knew that it was the “actual” server terminating HTTPS.

Even still, the difference between this and e2e encryption isn’t something an end user is really equipped to evaluate IMO. The threat model is practically different vs e2e no-encryption.

Cloudflare also supports reencryption over the net which is useful if your hosting provider supports HTTPS but not via a custom domain (e.g. Google clouds GCS (S3))

[kelnos]

No, I didn't make that stronger claim; if that's what it sounded like, I apologize for the poor wording. I was definitely assuming "terminate TLS at load balancer and proxy in the clear over internal, private network" as a common, long-established practice that I have no problem with.

With services like Cloudflare, you can terminate TLS at CF, and then proxy over the public internet to the server that actually serves the page, which I think defeats a lot of the purpose of TLS, and I can never know ahead of time when I request a page of HTTPS if this will in fact be what's happening.