Hacker News Reader

Comment by dangerlibrary | Hacker News Reader

I put off adding TLS certs to my personal website for years. It's just a few static files served by nginx on a server - there wasn't a great reason to bother, I thought.

It took me almost exactly 3 minutes start to finish with letsencypt. Where 'start' was "I should stop putting that off" and typing "letsencrypt.com" into a browser, and 'finish' was nginx serving up https:// on all my domains. I'm genuinely curious what nginx could possibly do to improve the situation there.

View on HN

It's true that setup is simple enough but what other servers like Caddy provide is automated renewals.

You don't have to mess with having a .well-known always accessible on each domain, for example. Caddy does it for you and only when it's needed.

Caddy targets single instances. No coordination is required to avoid receiving receive multiple certificates for multiple instances for same domain.

Nginx has a profit from big business that would require coordination to avoid multiple certificates. For comparison, it is worth noting that to ensure such coordination, Traefik requires an Enterprise plan and a separate agent. Such a business also often has mechanisms for storing certificates, so they do not necessarily want to integrate it into Nginx.

With Caddy, you can cluster easily by either sharing its filesystem data storage across machines, or configuring a different storage driver (redis, consul, db, etc.) and they will automatically coordinate for cert issuance. Caddy writes a lock file to the storage which prevents multiple instances from stepping on eachother's toes.

I recently moved to Caddy. Out-of-the-box TLS, HTTP3, Dumbed-down simple configuration, static files... it has been a breath of fresh air.

Caddy is amazing.

Still irritated that they ship it with an unprotected admin endpoint enabled by default on localhost:2019 that eats JSON and allows reconfiguration of the webserver like adding new sites that enable further attacks.

Put "{ admin off }" as a separate block in the root Caddyfile to disable it.

Our view is that localhost:2019 is inherently protected though - that only allows requests from the same machine. If you're running the machine with shared users, then of course it's up to you to further secure things.

That said, see https://github.com/caddyserver/caddy/issues/5317, we are considering changing the default, but that would be a breaking change although it would likely be a transparent change for most users. The default that makes the most sense depends on the platform and installation method, which is why it's complicated.

SSRF is a thing, just because you trust the code doesn't mean you've eliminated all security risks. The tools we use in the industry should all have secure defaults.

Glad to hear you're considering changing the default!

It would be enough for me if Caddy generated a password (that's hard for attackers to predict) on first launch, set that in a config file it has write access to (autosave.json for example), and then required Basic auth using this password unless the configuration specified otherwise. My problem is that this endpoint is entirely unauthenticated.

Have you demonstrated SSRF on a server that is not running insecure or untrusted code (i.e. is not already compromised)?

We have yet to see this, but if we do see a practical demonstration, we're happy to reconsider.

You've never seen an application with an SSRF vulnerability? I've encountered multiple working as a penetration tester.

This is a horrible approach to security. Bad. Bad. Bad.

Making decisions based on demonstration of practical attacks is "bad bad bad"?

Assuming that everyone on local host should have admin access to the web server is an extremely bad default, yes. Listening on ports that the user has not requested is bad enough but doing so without any authentication on that interface is bonkers.

What is the problem here, that is any different from allowing untrusted code on your machine? Yes, if you don't trust your other users you need to lock down your system. That's not new or unique to Caddy, and indeed you can lock down Caddy too. Once the machine is popped locally it's already game over, authentication can't prevent that.

Large enterprise codebases will almost always have some security vulnerabilities in them but are still considered trusted code. Caddy is a fine alternative for ingress to such applications if you ask me, maybe a little on the immature side, but it's certainly getting there. An admin might absolutely pick Caddy for ingress in order to keep config simple, writing a Caddyfile, and ending up with the aforementioned admin endpoint enabled by mistake.

Defense works in layers. Punching through one of those layers makes securty worse even if that layer was not the first or the primary defense.

The problem here is that a priviledged process (and yes, a process that has access to Port 80 and 443 is priviledged even if it doesn't run as root) gives unauthenticated control to less priviledged processes.

With good security design you don't lock things down as needed but instead start fully locked down and open up only the accesss you really need.

> With good security design you don't lock things down as needed but instead start fully locked down and open up only the accesss you really need.

This. @mholt what we're arguing for is just to have secure defaults.

Also written in a memory-safeish language.

Yes -- hugely underrated. Memory safety vulnerabilities are the cause of 60-70% of exploits [0] including the infamous Heartbleed. Caddy is not susceptible to these types of vulnerabilities. That we continue to deploy C code to the edge -- including software we think is hardened like nginx or Apache or OpenSSL -- boggles my mind.

[0]: https://www.memorysafety.org/docs/memory-safety/

Caddy does it all automatically and you don’t have to remember to do things by hand.

Check what caddy does. I think that is what op is after

Lots of folk have mentioned Caddy, but I'd like to also mention Traefik which kind of does the same thing but I found it to be less of a pain in the arse.

Traefik has a very verbose config with non-sensible defaults; Caddy works out of the box with 1-3 lines to setup your domain and sensible defaults.

What's the pain?

Tarefik because it is better architectured, auto discovery of docker services , battle tested

Link for others curious about the discovery:

https://doc.traefik.io/traefik/providers/docker/

(but preferring Caddy so far)

That can be done with Caddy as well: https://github.com/lucaslorentz/caddy-docker-proxy

This didn't work when I tried Caddy before, and it was the entire thing I needed to do.

I should revisit Caddy and see how it gets on.

It didn't cope with services starting and stopping well, and couldn't provision services from docker (at least when I looked at it).

Could you elaborate? We'd like to improve where practical.

Reply on news.ycombinator.com