Caddy: tls: Remove max_certs

[mholt]

1. What would you like to have changed?

Remove max_certs from the tls directive.

2. Why is this feature a useful, necessary, and/or important addition to this project?

In our experience, most people use max_certs with very high values ( > 100000!) to serve an indefinite number of customer websites. This is pointless and opens them up to DoS attacks and other forms of abuse.

This would be a breaking change (but justifiable because using max_certs with an insanely high value opens the server to abuse) and I think we should get it in before 1.0.

3. What alternatives are there, or what are you doing in the meantime to work around the lack of this feature?

On-Demand TLS should require the ask subdirective instead, which must explicitly allow a domain to be issued a certificate.

One alternative is to limit the maximum value of max_certs to, say, 100, so that it can be used for testing but not practical for use at scale.

4. Please link to any relevant issues, pull requests, or other discussions.

n/a

[polyscone]

I don't think it's worth removing max_certs if the only argument for it is that ask can be used as an alternative instead, purely because you could make the same argument for the ask directive where someone could just set up a URL to always return 200 no matter what.

Going by this same argument is it really worth limiting max_certs to a maximum number? Again, a URL that always returns 200 is arguably worse than an unreasonably high max_certs value. After all, at least max_certs has a maximum value, whereas ask can essentially be considered unlimited in the damage it can cause.

Trying to help users avoid DoS is great and all, but I can't help but feel that if they read the documentation (which they must of to have found max_certs in the first place), then they are accepting responsibility for their actions.

Maybe Caddy should take a less invasive stance on this issue and just start printing out warnings in the logs when max_certs is over 100 or something like that?

In the end, whilst I understand your concern, I think that removing max_certs entirely is a bit of a chocolate teapot. People are setting max_certs to a high value in most cases because it's the path of least resistance, but unless you get rid of on-demand TLS entirely, which would make Caddy unusable for many, I think the best course of action is simply logging prominent warnings for people to see.

[whitestrake]

Going by this same argument is it really worth limiting max_certs to a maximum number? Again, a URL that always returns 200 is arguably worse than an unreasonably high max_certs value. After all, at least max_certs has a maximum value, whereas ask can essentially be considered unlimited in the damage it can cause.

ask also has no internal cooldown / rate limit, so simply asking localhost on port 2015 with a status 200 / site _in the same Caddyfile_ on that port is indeed the superior method to abuse this functionality, anyway. max_certs, other than its total limit, only pulls one cert every ten minutes past the first ten certs (see: https://github.com/mholt/certmagic/blob/ee1543e2f234dc5e8eb3c7e76cbafb89398dd455/certmagic.go#L340-L347).

I'm disinclined to remove features from the web server with the intent of nannying users intent on abusing a function and in turn having their web server abused. LetsEncrypt have their own rate limits to protect themselves from bad actors.

[mholt]

All fair points! I agree.

[ntcong]

I saw that now max_certs is deprecated. Didn't you agree with all the point above? I'm interested to know what's the plan with max_certs. Can you share?

[francislavoie]

Unfortunately max_certs was broken after a bunch of refactors of CertMagic, the underlying lib implementing TLS logic. There's more info in this commit https://github.com/mholt/certmagic/commit/be4f86a2eb604498d97bea139811d1df3d578138

[mholt]

@ntcong

I saw that now max_certs is deprecated. Didn't you agree with all the point above? I'm interested to know what's the plan with max_certs. Can you share?

Yeah, good question. The problem with this issue is that it assumed max_certs was implemented correctly. @francislavoie is right, although technically, refactoring _exposed_ the weakness in the design, which the refactoring also fixed. The limitations with max_certs with which I agreed in my post above were related to the specific implementation which was kind of inconsistent, ignoring the fact that it doesn't actually offer good protection because of the hodge-podge of different factors that went into deciding when a cert could be obtained.

max_certs is deprecated now that the design has been improved in CertMagic, which allows for better protection mechanisms, notwithstanding my agreement to the reasons to keep it with the old (and incorrect) CertMagic design.

Hopefully that makes some sense.

It's a bit awkward to try to support all the features of CertMagic's new design in Caddy 1, and kind of a waste of time, since it's already fully functional in Caddy 2, which has a _much_ better integration of On-Demand TLS. For example, Caddy 2 offers true rate limits which actually work. :) It is simpler, more correct when running for a long time and through config reloads, etc. It offers actual protection unlike max_certs, and is just as easy to configure/enable in Caddy 2.