Issue Details
(sorry can't reopen an closed issue but this issue relates to the following issue: https://github.com/caddyserver/caddy/issues/5955)
... I understand the concern about relying on client IPs for security decisions, but there's a legitimate use case here that's not about security — it's about resource protection and abuse prevention.
The problem:
When running a white-label SaaS or multi-tenant platform with on-demand TLS for customer CNAMEs, distributed botnet attacks can exhaust Let's Encrypt rate limits by requesting certificates for thousands of random, invalid domains. The ask endpoint can validate domains against a database, but without the client IP:
- Rate-limiting abusive clients at the application layer becomes impossible
- Fail2ban-style progressive bans for repeated offenders can't be implemented
- Attack pattern analysis is impossible (detecting when the same IP hits multiple invalid domains)
Current workaround:
Operators are forced to add nginx/HAProxy in front of Caddy purely to capture IPs and implement rate limiting — adding complexity, latency, and another potential failure point.
Proposed solution:
Pass the client IP as an optional query parameter to the ask endpoint:
ask http://127.0.0.1:9999?domain={domain}&client_ip={remote_ip}
This would allow operators to:
Log and analyze attack patterns
Implement progressive bans (e.g., 3 invalid requests → 24h ban)
Reduce server load by blocking repeat offenders before TLS handshake completion
Why this isn't a "false sense of security":
- The IP wouldn't be used for authentication (the ask endpoint still validates domains)
- It's used for abuse mitigation (same use case as fail2ban, CloudFlare rate limiting, etc.)
- Operators understand IPs can be spoofed, but in practice, real-world botnet attacks use actual source IPs that can be effectively blocked
This feature would significantly help operators protect their certificate quota and server resources against distributed attacks, which is a real problem for anyone offering dynamic SSL on multi-tenant platforms.
Would you reconsider this feature for abuse prevention use cases?
Best regads
Thomas
Assistance Disclosure
No response
If AI was used, describe the extent to which it was used.
No response
Issue Details
(sorry can't reopen an closed issue but this issue relates to the following issue: https://github.com/caddyserver/caddy/issues/5955)
... I understand the concern about relying on client IPs for security decisions, but there's a legitimate use case here that's not about security — it's about resource protection and abuse prevention.
The problem:
When running a white-label SaaS or multi-tenant platform with on-demand TLS for customer CNAMEs, distributed botnet attacks can exhaust Let's Encrypt rate limits by requesting certificates for thousands of random, invalid domains. The ask endpoint can validate domains against a database, but without the client IP:
Current workaround:
Operators are forced to add nginx/HAProxy in front of Caddy purely to capture IPs and implement rate limiting — adding complexity, latency, and another potential failure point.
Proposed solution:
Pass the client IP as an optional query parameter to the ask endpoint:
ask http://127.0.0.1:9999?domain={domain}&client_ip={remote_ip}
This would allow operators to:
Log and analyze attack patterns
Implement progressive bans (e.g., 3 invalid requests → 24h ban)
Reduce server load by blocking repeat offenders before TLS handshake completion
Why this isn't a "false sense of security":
This feature would significantly help operators protect their certificate quota and server resources against distributed attacks, which is a real problem for anyone offering dynamic SSL on multi-tenant platforms.
Would you reconsider this feature for abuse prevention use cases?
Best regads
Thomas
Assistance Disclosure
No response
If AI was used, describe the extent to which it was used.
No response