4 ms·

This is something I've looked for many times before. I actually don't want the CDN side of Cloudflare (some parts of my app are incompatible with the way their

by ezekg 3y ago

This is something I've looked for many times before. I actually don't want the CDN side of Cloudflare (some parts of my app are incompatible with the way their CDN works), but I do want the WAF. But Cloudflare doesn't let you disable the CDN side of their service. It's all or nothing. Anybody have alternatives to Cloudflare's WAF?

saurik 3y ago
Have you looked at the WAF from AWS? I am using it on one of my sites to add a rate limit and it was reasonably easy to implement.
- ezekg 3y ago
  I have not. I'll have to see if it's compatible with Heroku.
solardev 3y ago
> But Cloudflare doesn't let you disable the CDN side of their service. It's all or nothing. Are you sure about this? It's been a year or so since I've used it, but I remember being able to disable a lot of specific performance/caching stuff (where the CDN comes in) via its Page Rules and "Cache Level - Bypass": https://developers.cloudflare.com/support/page-rules/understanding-and-configuring-cloudflare-page-rules-page-rules-tutorial/#summary-of-page-rules-settings https://developers.cloudflare.com/support/page-rules/underst...
- ezekg 3y ago
  Yes, unfortunately. I've confirmed it with their support. Requests always hit their CDN. For example, set up a small server that sends the following response headers: Date: <current server timestamp> Original-Date: <same as Date> Cloudflare will always rewrite the Date header, you just won't notice it until the Date header happens to fall on a time a few ms from the next second (e.g. Wed, 13 Sep 2023 22:02:51.999). This is because by the time Cloudflare processes the request and overwrites your Date header, the Date has changed, causing the Date header to differ from Original-Date. This resulted in a considerable headache on my end [^0], because the Date header was being used for cryptographic signatures. So 1/100 requests would have an invalid signature for no apparent reason. But the reason was Cloudflare not acting as a good proxy, overwriting the Date header that had already been set. [^0]: https://news.ycombinator.com/item?id=28157629 https://news.ycombinator.com/item?id=28157629
  - solardev 3y ago
    I see. That's a good find. Thanks for the details! And sorry about your edge (no pun intended) case.
  - llama052 3y ago
    is using your own headers for date not the solution here? I'd imagine a lot of proxies in general will overwrite that date. At least on the corporate proxy side of things.
    - ezekg 3y ago
      It's the ideal solution (and one I already implemented with a Keygen-Date header), yes, but this bug was discovered months after the feature was introduced and relied upon (I run an API product). So it's not as simple as using a different header, since previous clients will still be on the Date header. Backwards compatibility can be a bitch.
  - aknfxb3m 3y ago
    Will your solution work with any CDN at all? It seems the issue is not specific to Cloudflare. `Date` is a registered field [0] used by origin server as defined in RFC 9110 [1]. Any CDN server will add its own date to that header since it's acting as the origin server for that request. For Cloudflare in particular, you could try setting Cache-Control to Private=Date and see if the edge cache skips the override [2]. What you want seems to be a tunnel with WAF. In that case, a Cloudflare Worker might be a workaround to the native caching layer but I'm not sure if that has any effect on the edge device updating the Date header or not. Workers do support WAF. 0 - https://www.iana.org/assignments/http-fields/http-fields.xhtml#field-names https://www.iana.org/assignments/http-fields/http-fields.xht... 1 - https://www.rfc-editor.org/rfc/rfc9110.html https://www.rfc-editor.org/rfc/rfc9110.html 2 - https://developers.cloudflare.com/cache/concepts/cache-control/ https://developers.cloudflare.com/cache/concepts/cache-contr...
    - ezekg 3y ago
      I don't know, and that's why I want a WAF without a CDN. I don't need a CDN at all, and I wish I could disable Cloudflare's. But per RFC 9110 [^0], "the Date header field represents the date and time at which the message was originated." The message comes from my server, not Cloudflare. If they're getting the message from me, i.e. it's not cached by their CDN, they should leave the Date header alone because the message didn't originate with them. [^1] Maybe I have a misunderstanding of where Cloudflare sits as the "origin server" when their CDN isn't used for caching (i.e. it's bypassed as much as is allowable). I would think my server is the "origin" and theirs is the "edge." And unfortunately, workers do not allow you to set the Date header -- Cloudflare support and I already tried that a couple years back (i.e. setting Date = Keygen-Date via a worker). I will take a look at 2. I doubt that'd work, but it's worth a try. [^0]: https://www.rfc-editor.org/rfc/rfc9110.html#name-date https://www.rfc-editor.org/rfc/rfc9110.html#name-date [^1]: https://httpwg.org/specs/rfc7230.html#rfc.section.5.7.2 https://httpwg.org/specs/rfc7230.html#rfc.section.5.7.2
solardev 3y ago
Fastly has one too, but I don't have direct experience with it: https://www.fastly.com/products/web-application-api-protection https://www.fastly.com/products/web-application-api-protecti... Imperva also has one, but I can't recommend that one. We had them before Cloudflare and they were ridiculously expensive and not very good. Cloudflare was dramatically better and several orders of magnitude cheaper. That was back in like 2015 though so maybe it's different now.
- ezekg 3y ago
  Looking into Fastly WAF now. Thanks for the recommendation.
  - anildash 3y ago
    I don't work on that team, but I work _with_ that team and consistently hear that people think the support is excellent, so be sure to ask about that as you reach out to them.

by ezekg 3y ago

saurik 3y ago

Have you looked at the WAF from AWS? I am using it on one of my sites to add a rate limit and it was reasonably easy to implement.

ezekg 3y ago
I have not. I'll have to see if it's compatible with Heroku.

solardev 3y ago

> But Cloudflare doesn't let you disable the CDN side of their service. It's all or nothing. Are you sure about this? It's been a year or so since I've used it, but I remember being able to disable a lot of specific performance/caching stuff (where the CDN comes in) via its Page Rules and "Cache Level - Bypass": https://developers.cloudflare.com/support/page-rules/understanding-and-configuring-cloudflare-page-rules-page-rules-tutorial/#summary-of-page-rules-settings https://developers.cloudflare.com/support/page-rules/underst...

ezekg 3y ago
Yes, unfortunately. I've confirmed it with their support. Requests always hit their CDN. For example, set up a small server that sends the following response headers: Date: <current server timestamp> Original-Date: <same as Date> Cloudflare will always rewrite the Date header, you just won't notice it until the Date header happens to fall on a time a few ms from the next second (e.g. Wed, 13 Sep 2023 22:02:51.999). This is because by the time Cloudflare processes the request and overwrites your Date header, the Date has changed, causing the Date header to differ from Original-Date. This resulted in a considerable headache on my end [^0], because the Date header was being used for cryptographic signatures. So 1/100 requests would have an invalid signature for no apparent reason. But the reason was Cloudflare not acting as a good proxy, overwriting the Date header that had already been set. [^0]: https://news.ycombinator.com/item?id=28157629 https://news.ycombinator.com/item?id=28157629
- solardev 3y ago
  I see. That's a good find. Thanks for the details! And sorry about your edge (no pun intended) case.
- llama052 3y ago
  is using your own headers for date not the solution here? I'd imagine a lot of proxies in general will overwrite that date. At least on the corporate proxy side of things.
  - ezekg 3y ago
    It's the ideal solution (and one I already implemented with a Keygen-Date header), yes, but this bug was discovered months after the feature was introduced and relied upon (I run an API product). So it's not as simple as using a different header, since previous clients will still be on the Date header. Backwards compatibility can be a bitch.
- aknfxb3m 3y ago
  Will your solution work with any CDN at all? It seems the issue is not specific to Cloudflare. `Date` is a registered field [0] used by origin server as defined in RFC 9110 [1]. Any CDN server will add its own date to that header since it's acting as the origin server for that request. For Cloudflare in particular, you could try setting Cache-Control to Private=Date and see if the edge cache skips the override [2]. What you want seems to be a tunnel with WAF. In that case, a Cloudflare Worker might be a workaround to the native caching layer but I'm not sure if that has any effect on the edge device updating the Date header or not. Workers do support WAF. 0 - https://www.iana.org/assignments/http-fields/http-fields.xhtml#field-names https://www.iana.org/assignments/http-fields/http-fields.xht... 1 - https://www.rfc-editor.org/rfc/rfc9110.html https://www.rfc-editor.org/rfc/rfc9110.html 2 - https://developers.cloudflare.com/cache/concepts/cache-control/ https://developers.cloudflare.com/cache/concepts/cache-contr...
  - ezekg 3y ago
    I don't know, and that's why I want a WAF without a CDN. I don't need a CDN at all, and I wish I could disable Cloudflare's. But per RFC 9110 [^0], "the Date header field represents the date and time at which the message was originated." The message comes from my server, not Cloudflare. If they're getting the message from me, i.e. it's not cached by their CDN, they should leave the Date header alone because the message didn't originate with them. [^1] Maybe I have a misunderstanding of where Cloudflare sits as the "origin server" when their CDN isn't used for caching (i.e. it's bypassed as much as is allowable). I would think my server is the "origin" and theirs is the "edge." And unfortunately, workers do not allow you to set the Date header -- Cloudflare support and I already tried that a couple years back (i.e. setting Date = Keygen-Date via a worker). I will take a look at 2. I doubt that'd work, but it's worth a try. [^0]: https://www.rfc-editor.org/rfc/rfc9110.html#name-date https://www.rfc-editor.org/rfc/rfc9110.html#name-date [^1]: https://httpwg.org/specs/rfc7230.html#rfc.section.5.7.2 https://httpwg.org/specs/rfc7230.html#rfc.section.5.7.2

solardev 3y ago

Fastly has one too, but I don't have direct experience with it: https://www.fastly.com/products/web-application-api-protection https://www.fastly.com/products/web-application-api-protecti... Imperva also has one, but I can't recommend that one. We had them before Cloudflare and they were ridiculously expensive and not very good. Cloudflare was dramatically better and several orders of magnitude cheaper. That was back in like 2015 though so maybe it's different now.

ezekg 3y ago
Looking into Fastly WAF now. Thanks for the recommendation.
- anildash 3y ago
  I don't work on that team, but I work _with_ that team and consistently hear that people think the support is excellent, so be sure to ask about that as you reach out to them.