4 ms·

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 cr

by ef4 9y ago

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.

Retric 9y ago
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.
1wheel 9y ago
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 https://pastebin.com/N2sbvULA
- kelnos 9y ago
  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 9y ago
    Try `certbot renew --post-hook "/etc/init.d/nginx reload`, which will only reload nginx if at least one certificate changed :).
robocat 9y ago
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 9y ago
  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 9y ago
    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 9y ago
      Reverse proxy were usally not routed through the Internet, only a local network.

by ef4 9y ago

Retric 9y ago

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.

1wheel 9y ago

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 https://pastebin.com/N2sbvULA

kelnos 9y ago
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 9y ago
  Try `certbot renew --post-hook "/etc/init.d/nginx reload`, which will only reload nginx if at least one certificate changed :).

robocat 9y ago

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 9y ago
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 9y ago
  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 9y ago
    Reverse proxy were usally not routed through the Internet, only a local network.