Rate limits and proxy

[DanCvrcek]

I wonder if someone can help me.

I need to run a bunch of certbot clients via a single proxy.

Will Let’s Encrypt accept X-Forwarded-For header (or any other) when updating counters that are per IP address? … or will all requests count against the proxy’s IP?

Thanks

[orangepizza]

Wouldn’t someone able to nullify rate limit if LE accept that for rate limit by posting random ip in that header?

[cpu]

@orangepizza

Wouldn’t someone able to nullify rate limit if LE accept that for rate limit by posting random ip in that header?

Exactly true.

@DanCvrcek

Will Let’s Encrypt accept X-Forwarded-For header (or any other) when updating counters that are per IP address? … or will all requests count against the proxy’s IP?

There's no way to override the source IP address that is used for our rate limit calculations vs the one seen on the wire at the edge of our infrastructure. As @orangepizza mentioned this would be a security vulnerability if it were possible and we would want to treat it that way.

All of the proxy's requests will count against the proxy's IP for the purposes of rate limiting. Are you worried about the new accounts limit, the failed validations limit, the overall reqs limit? All of the above? Rate limit adjustments may be possible depending on the concern/scale.

[DanCvrcek]

@cpu

Are you worried about the new accounts limit

interesting - I obviously could see it as a way to bypass rate limits but didn't realise there's a security aspect of that - is there a particular security concern here ... other than DoS?

Well, we need this to correctly count requests to raise warning flags. We are finishing the monitoring proxy for ACMEv2 so we need to correctly set up counters. We can do a simple pass-through or a "deep" proxy when the proxy has its own account. So it seems that each option has its own highlights and low-points.

I believe the main restriction is the new accounts limit - although IPv6 500/3h should be ok for most. I think the rest could be managed as they are caused by errors/mistakes.

[cpu]

@DanCvrcek

interesting - I obviously could see it as a way to bypass rate limits but didn’t realise there’s a security aspect of that - is there a particular security concern here … other than DoS?

Principally DoS. We don't do any fine-grained access control based on request source IPs but we do block broken/malicious clients by IP and effective rate limits are important to maintaining service availability.