Tell HN: Cloudflare is rewriting my Date response headers

4 points

5 years ago

Earlier this year I added HTTP response signatures to my business's API, per the HTTP draft spec [0]. These signatures utilize the standard Date response header to help prevent replay attacks among other attack vectors. But to my dismay, Cloudflare rewrites the Date response header at the edge. Meaning, if a particularly unlucky request leaves my servers at 14:01:26.999 with a Date header "Thu, 12 Aug 2021 14:01:26 GMT" and takes ~1ms to process at the edge, the Date header from Cloudflare ends up being "Thu, 12 Aug 2021 14:01:27 GMT". This is problematic when it comes to HTTP response signatures, since the signature is now invalidated. This ends up causing intermittent response signature verification failures.

Cloudflare's support previously suggested that I use (and pay for) an unbound Cloudflare Worker to manually set the Date header to the value of some other internal, unmodified X-Date header. I tried this, but that's actually a noop! So not only are they rewriting the Date response header, but there is no way to stop this behavior. Looking at the HTTP spec, this seems in violation of it for a proxy to rewrite the Date after it has already been set [1] [2], but I can't be certain (keyword: "date and time at which the message originated"). Either way, this is unexpected behavior -- I'd expect every header I send in a response to actually make it, unmodified, to the client. But it seems that's not the case with CF. Honestly, I find this to be unacceptable behavior, but perhaps I'm out of line?

As you could imagine, this issue has been frustrating and was incredibly hard to debug. I spent days digging into and stepping through Puma and Rails internals, thinking they were somehow overriding my Date header before sending the response.

CF support has made it clear that this is a 'will not fix.' Thus, here we are. Perhaps there are a few CF engineers on HN that can help here.

[0]: https://tools.ietf.org/id/draft-cavage-http-signatures-08.html

[1]: https://datatracker.ietf.org/doc/html/rfc7231#section-7.1.1.2

[2]: https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.18

p.s. anybody have a good Cloudflare alternative for WAF?

2 comments