Put the following in your Caddyfile at the lowest scope to disable it:
{
admin off
}The API can still be there, I'm just asking for better integration where feasible. Signal handling on Linux/similar
It's silly to tell my init process to go out 'to the network' to do something it can do directly against the child.
I would not expect turning off an admin API to effectively limit my way to administer the process.
Services will generally ordain a path for a config, overridable with arguments. The same file used then is what is re-read on reload.
Argument/command line changing during a reload isn't a thing, that's restarting. We give it config files as an argument (or implicit default) so that can be reloaded.
It's uncommon to start a process with one file, decide you want a new file path, but keep the PID.
But it won't be possible to add signals support. We've thought hard about it but it's simply not a fit. There's discussion in GitHub: https://github.com/caddyserver/caddy/issues/3967
ie: admin interface disabled, I can't reload to bring it back... because that depends on it.
With sockets we gain a permission model; one simply being in the 'localhost' scope can't do funny/scary things - either a user or another service on the system.
Thank you for the discussion, I'll give it a read - have a meeting then I can finally use my computer to 'catch up'
It would be more appropriate to handle signals, particularly SIGHUP. That's how most services have been handling reloads.
It's fine to offer an admin API, especially if I want a peer to be able to affect the local instance, but this shouldn't be the position init is placed in.
Put simply, the init process is what we depend on if everything else fails.
What if rm would by default just delete everything, as it assumes that makes sense? Stupid comparison, I know, also a stupid default.
https://caddyserver.com/docs/json/admin/remote/access_contro...
admin listen unix//var/run/caddy/admin.sockA blind SSRF vulnerability (with payload control) in your application could be used to gain full control over the reverse proxy resulting in the attacker gaining full unfettered access to your network.
If you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
Edit, I just checked the Caddyfile for one of my sites. There is no config for redirecting HTTP to HTTPS is does it automatically. So this is entirely unnecessary.
This is unrelated to sites hosted using HTTP. I was clumsily using the term "HTTP" to refer to the fact that this configuration mechanism is based on HTTP-communication.
Seems counter to their objective of having secure defaults.
I'd imagine if someone already has local access to the server, it's already too late.
Also SSRF risks as mentioned elsewhere ...
You could have a blind SSRF vulnerability in an application and while that's not great, it is difficult for an attacker to exploit successfully.
If the attacker knows or guesses you're hosting Caddy on the same machine, they know you most likely have an admin interface on localhost:2019 that they can use to make further local network requests and also makes it possible for them to access the results of their local network requests they were making through the blind SSRF vulnerability hypothesised above.
Basically, if you're not using it (and you shouldn't be using such functionality on a production machine), then you don't need it and should disable it, see: https://owasp.org/Top10/A05_2021-Security_Misconfiguration/
Actually, most everyone wants zero-downtime config reloads. The API is necessary to perform config reloads.
As others have said, you may use a unix socket instead for the admin endpoint. And see https://news.ycombinator.com/item?id=37482096, we plan to make that the default in certain distributions.
Of course it isn't. It could reload the config from the same path it loaded the config from in the first place. Like practically all other software has done for decades.
Happy to hear you're moving to sockets by default on *nix!
However, I'd like to point out that the default should be in the binary, not in the distros default environment variables, otherwise it won't reach people who build their own binary, and depending on how you start your Caddy server you may clear environment variables for that process, and end up with the insecure HTTP-based admin endpoint enabled by accident.
If you're correct that I'm overestimating users then what are you guys doing? You're expecting users to know how to secure their Caddy configuration when in reality most users probably have no idea that this API even exists, they'll put their config in Caddyfile, start the server, and be done with it.
We should be expecting that they don't know anything about the risks involved with leaving an unauthenticated HTTP API on localhost, and instead shipping a default that doesn't place their system and network at unnecessary risk.
Exactly, which is why the environment variable approach is perfectly fine. The env var will be set in the systemd config.
> You're expecting users to know how to secure their systems
Again, our view is that the TCP socket for admin is secure enough for 99.99% of users, and has been for over 3 years since Caddy v2 was released. We've still not seen any evidence of a practical exploit in the wild.
Security follows the Swiss cheese model: each individual measure has known limitations but by layering them, you reduce the overall number of attack vectors.
Getting the server to make arbitrary HTTP requests is bad, yes, but limiting what the attacker can do with that makes it less dangerous if you somehow screw that one thing up.