4 ms·

What does it do that certbot doesn't? Personally, I don't see the benefit of bundling certificate renewals with the HTTPS server.

mholt 7y ago
A quick perusal of the Let's Encrypt forums will reveal a few issues. For one, it's easy to misconfigure. There's a lot of surface area it has to cover in the web server and there's a lot that can go wrong. It can also be tricky to install since it is separate from your web server and has a number of complex depeneldency requirements (like many large Python programs). And because it's an external dependency, there's no way the server can react to errors in CertBot, only CertBot can control the server, so you don't get the benefit of duplexed interactions. Caddy is written in Go, a memory safe language. I cannot overstate how significant it is that most servers like ngixn, Apache, and HAProxy are written in C and cannot offer the same security guarantees. Caddy will also staple OCSP, in the most robust way compared to other servers. It has weathered outages that took Apache and NGINX sites down (in Firefox). We've also seen CertBot consume high amounts of resources at scale, whereas Caddy can handle thousands of certs no problem. That's why some companies have talked to me about why they switched. Caddy can coordinate cert management in a cluster. This happens automatically when configured with the same storage backend. CertBot doesn't do that. Caddy works great behind reverse proxies, or as the reverse proxy. Perhaps most importantly, Caddy is the only server to use HTTPS by default without needing any explicit configuration. You simplify your deployment workflows and have less room for things to go wrong. There's also a values statement here... If you think privacy and security are important, you choose software that enables privacy by default because it aligns with your values. Sure, any number of solutions can get you TLS and a few even get you TLS via ACME, but Caddy (2) is highly optimized to handle the edge cases and scaling requirements a lot of sites have these days.
- vinaypai 7y ago
  I don't meant to pooh-pooh your project, but Go's memory safety isn't some kind of automatic security guarantee... especially when it comes with a giant downside of having to run as root. Every other production-grade server drops privileges as soon as possible, for a very good reason.
  - mholt 7y ago
    Go does bounds checking and doesn't have dangling pointers, so it's inherently safe from buffer overflows. You don't have to run Caddy as root in production, even to bind to low ports. (None of my sites do.) https://memorysafety.fail https://memorysafety.fail for more info on memory unsafety.
    - vinaypai 7y ago
      Thank you for your condescending reply. I understand Go's memory model quite well (and have used Go quite a bit). News flash: you can have bugs of other kinds besides buffer overflows.
      - mholt 7y ago
        Er, sorry, I wasn't being condescending. I intended to clarify some relevant facts, please don't take it personally. You had said: > Go's memory safety isn't some kind of automatic security guarantee... But in some cases, it is. I'm not claiming more than that, nor am I saying that you can't have "bugs of other kinds" -- on which point I agree with you.
        vinaypai 7y ago
        > Er, sorry, I wasn't being condescending. I intended to clarify some relevant facts, please don't take it personally. Fair enough, it's easy to misunderstand the intended tone in online comments.
  - justinclift 7y ago
    Why would a Go server need to run as root? Asking because I run Go based servers (in production) on Linux, and they're not running any of the Go processes as root.
    - vinaypai 7y ago
      https://github.com/caddyserver/caddy/issues/528 https://github.com/caddyserver/caddy/issues/528 It seems like they've fixed their systemd config though to run as a non-privileged user, so that shouldn't be an issue. But it seems like Go processes can't drop privileges because of an open issue with the runtime.
discreditable 7y ago
Fail to start if it can't reach the ACME server https://github.com/caddyserver/caddy/issues/1680 https://github.com/caddyserver/caddy/issues/1680
- mholt 7y ago
  That was 3 years ago when ACME was still a new and unstandardized protocol. That was one of the worst days of my life, trying to fix that while finishing my NIPS paper. If you read the issue you'll see that we fixed that and learned from it.

mholt 7y ago

A quick perusal of the Let's Encrypt forums will reveal a few issues. For one, it's easy to misconfigure. There's a lot of surface area it has to cover in the web server and there's a lot that can go wrong. It can also be tricky to install since it is separate from your web server and has a number of complex depeneldency requirements (like many large Python programs). And because it's an external dependency, there's no way the server can react to errors in CertBot, only CertBot can control the server, so you don't get the benefit of duplexed interactions. Caddy is written in Go, a memory safe language. I cannot overstate how significant it is that most servers like ngixn, Apache, and HAProxy are written in C and cannot offer the same security guarantees. Caddy will also staple OCSP, in the most robust way compared to other servers. It has weathered outages that took Apache and NGINX sites down (in Firefox). We've also seen CertBot consume high amounts of resources at scale, whereas Caddy can handle thousands of certs no problem. That's why some companies have talked to me about why they switched. Caddy can coordinate cert management in a cluster. This happens automatically when configured with the same storage backend. CertBot doesn't do that. Caddy works great behind reverse proxies, or as the reverse proxy. Perhaps most importantly, Caddy is the only server to use HTTPS by default without needing any explicit configuration. You simplify your deployment workflows and have less room for things to go wrong. There's also a values statement here... If you think privacy and security are important, you choose software that enables privacy by default because it aligns with your values. Sure, any number of solutions can get you TLS and a few even get you TLS via ACME, but Caddy (2) is highly optimized to handle the edge cases and scaling requirements a lot of sites have these days.

vinaypai 7y ago
I don't meant to pooh-pooh your project, but Go's memory safety isn't some kind of automatic security guarantee... especially when it comes with a giant downside of having to run as root. Every other production-grade server drops privileges as soon as possible, for a very good reason.
- mholt 7y ago
  Go does bounds checking and doesn't have dangling pointers, so it's inherently safe from buffer overflows. You don't have to run Caddy as root in production, even to bind to low ports. (None of my sites do.) https://memorysafety.fail https://memorysafety.fail for more info on memory unsafety.
  - vinaypai 7y ago
    Thank you for your condescending reply. I understand Go's memory model quite well (and have used Go quite a bit). News flash: you can have bugs of other kinds besides buffer overflows.
    - mholt 7y ago
      Er, sorry, I wasn't being condescending. I intended to clarify some relevant facts, please don't take it personally. You had said: > Go's memory safety isn't some kind of automatic security guarantee... But in some cases, it is. I'm not claiming more than that, nor am I saying that you can't have "bugs of other kinds" -- on which point I agree with you.
      - vinaypai 7y ago
        > Er, sorry, I wasn't being condescending. I intended to clarify some relevant facts, please don't take it personally. Fair enough, it's easy to misunderstand the intended tone in online comments.
- justinclift 7y ago
  Why would a Go server need to run as root? Asking because I run Go based servers (in production) on Linux, and they're not running any of the Go processes as root.
  - vinaypai 7y ago
    https://github.com/caddyserver/caddy/issues/528 https://github.com/caddyserver/caddy/issues/528 It seems like they've fixed their systemd config though to run as a non-privileged user, so that shouldn't be an issue. But it seems like Go processes can't drop privileges because of an open issue with the runtime.

discreditable 7y ago

Fail to start if it can't reach the ACME server https://github.com/caddyserver/caddy/issues/1680 https://github.com/caddyserver/caddy/issues/1680

mholt 7y ago
That was 3 years ago when ACME was still a new and unstandardized protocol. That was one of the worst days of my life, trying to fix that while finishing my NIPS paper. If you read the issue you'll see that we fixed that and learned from it.