Earlier quoted context omitted.
I don't know what you're on about. Just run Caddy and it does it all for you.
That is exactly what I am talking about. You say caddy. The next person will say nginx-proxy-manager. The next will say DNS challenge let's encrypt behind wireguard VPN. The next will say Traefik. The next will say CloudFlare tunnels. Everyone has their preferred solution and its always the best and simplest.
The web server deployment model breaks at hobby scale
61–70 of 75 posts
Re: The web server deployment model breaks at hobby scale
#62I can relate to the TLS termination issue. It is difficult to provide a self hosted version of a web app with a sensible TLS setup. The best is almost not to do it at all. Just have a docker image serve http/1.1 and document that a reverse proxy is required to expose the service. There are simply too many ways to do it and every sys admin/hobbyist has their own preferred way. For the anonymous and authenticated cachi…
No caddy. No cache. No proxy.
A lot of scrapers give up.
Log rate remains low. Actual visits even lower.
Peace of mind, for a while:
Re: The web server deployment model breaks at hobby scale
#63I have 5Gbps fiber at home. LAN is mostly 10Gbps. I'm hosting few hobbyist public websites. One is the library of hymns, songs, ... - mostly PDF, MP3, MIDI. OpnSense router -> Traefik -> Docker container. That Docker container runs on NAS, which is connected via 1Gbps port. Suddenly, last week I started to get over 1000 RPS. Was it scanner, parser, crawler, DDOS? I can't tell, as user agent was default Mac OS. It was…
Re: The web server deployment model breaks at hobby scale
#64Re: The web server deployment model breaks at hobby scale
#65Earlier quoted context omitted.
Fair enough, http is enough - I anyways have one caddy to rule them all. However, if your app is picky about reverse proxying, e.g. headers, please add a sample caddy config. It's often the first thing I'm looking for if I'm trying out a tool and want to host it under a subdirectory before configuring a subdomain.
No, HTTP is not enough, I submitted a couple HTTP-only links to HN lately, they got flagged within half an hour, even HN crowd can not open HTTP links anymore ;-)
My point was not to use http only as a finished solution, but to let the admin front the http-only service with their TLS termination solution of choice.
Re: The web server deployment model breaks at hobby scale
#66I have 5Gbps fiber at home. LAN is mostly 10Gbps. I'm hosting few hobbyist public websites. One is the library of hymns, songs, ... - mostly PDF, MP3, MIDI. OpnSense router -> Traefik -> Docker container. That Docker container runs on NAS, which is connected via 1Gbps port. Suddenly, last week I started to get over 1000 RPS. Was it scanner, parser, crawler, DDOS? I can't tell, as user agent was default Mac OS. It was…
INB4 someone complains about Cloudflare while not offering an alternative to these type of issues
Re: The web server deployment model breaks at hobby scale
#67Earlier quoted context omitted.
I'm glad unencrypted http/1.1 was deprecated. I want a privacy online. TLS also gives you much better data integrity guarantees. Some ISPs - particularly in the US - actively inject javascript code into websites served over plain HTTP. I just wish nginx / caddy / etc had better out-of-the-box support for letsencrypt. It would be way easier to set up if it was just built in to nginx. Let me specify my domain in my ngi…
Look at this from the Digital Sovereignty angle. AFAU Let's Encrypt gets its money from Google. There are other minor providers of similar services over the ACME protocol, but this does not change the fact that they issue the the majority of the free TLS certificates. We already had one centralized domain name system managed by the US Government that we have to hop through before publishing our content online for eve…
Here's how it could work: First, you generate a tls signing certificate. The signing cert gets stored in DNS. When anyone makes a DNS query, the response contains your root certificate's signature (HMAC). When you initiate a TLS connection, you check the root certificate in the cert chain against the signature provided over DNS.
The dns response would also need to be cryptographically signed by the dns provider. Instead of operating systems shipping trust roots of TLS cert providers, we ship the root certificates of DNS registrars. Eg, .com, .com.au, etc would each publish one or more root certificates that would get distributed with operating systems.
Trust already depends on dns (since that’s how you prove who you are to letsencrypt). So the whole system would rely on fewer trusted entities - which would hopefully make it more secure. It would be simpler to run - less organisations needing to do anything. And simpler to make use of, since you wouldn’t need programs like certbot to keep your tls certs up to date. This would also prevent the danger of malicious TLS providers being involved in MITM attacks on TLS.
Re: The web server deployment model breaks at hobby scale
#68Earlier quoted context omitted.
No, HTTP is not enough, I submitted a couple HTTP-only links to HN lately, they got flagged within half an hour, even HN crowd can not open HTTP links anymore ;-)
That's not really HN's fault but all modern browsers will warn the user before accessing an http site with a security warning. My point was not to use http only as a finished solution, but to let the admin front the http-only service with their TLS termination solution of choice.
Re: The web server deployment model breaks at hobby scale
#69Earlier quoted context omitted.
Look at this from the Digital Sovereignty angle. AFAU Let's Encrypt gets its money from Google. There are other minor providers of similar services over the ACME protocol, but this does not change the fact that they issue the the majority of the free TLS certificates. We already had one centralized domain name system managed by the US Government that we have to hop through before publishing our content online for eve…
Yea from a technical perspective I think it’s ridiculous that organisations like lets encrypt are even needed. DNS could easily service both roles and make letsencrypt redundant. Here's how it could work: First, you generate a tls signing certificate. The signing cert gets stored in DNS. When anyone makes a DNS query, the response contains your root certificate's signature (HMAC). When you initiate a TLS connection,…
That is, if they inject JS or modify the data in any way, they are liable for the content, otherwise not.
Re: The web server deployment model breaks at hobby scale
#70Earlier quoted context omitted.
Yea from a technical perspective I think it’s ridiculous that organisations like lets encrypt are even needed. DNS could easily service both roles and make letsencrypt redundant. Here's how it could work: First, you generate a tls signing certificate. The signing cert gets stored in DNS. When anyone makes a DNS query, the response contains your root certificate's signature (HMAC). When you initiate a TLS connection,…
I think we should have gone the legal route, forbidding JS injection in pasing HTML by carriers by e. g. conditioning their liability to the modification of data. That is, if they inject JS or modify the data in any way, they are liable for the content, otherwise not.
Computers are fast now. We should just encrypt everything that gets sent over the open internet.
The IETF put out a statement about this a few years ago. I agree with their stance.
> The IAB urges protocol designers to design for confidential operation by default. We strongly encourage developers to include encryption in their implementations, and to make them encrypted by default. We similarly encourage network and service operators to deploy encryption where it is not yet deployed, and we urge firewall policy administrators to permit encrypted traffic.
https://datatracker.ietf.org/doc/statement-iab-statement-on-...