New-nonce not providing correct Cache-Control headers

(I am aware that this is aaaaaaalmost certainly a boulder thing, but since I’ve only tested it on LE, and there’s the possibility that there’s something in the LE deployment of boulder that’s causing the issue, I’m posting here rather than creating an issue on boulder)

RFC8555, s7.2, says:

The server MUST include a Cache-Control header field with the “no-store” directive in responses for the newNonce resource, in order to prevent caching of this resource.

Reality, on the other hand, thinks differently:

$ wget -S -O - https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce --method=HEAD -q |& grep Cache-Control
  Cache-Control: public, max-age=0, no-cache
$ wget -S -O - https://acme-staging-v02.api.letsencrypt.org/acme/new-nonce --method=GET -q |& grep Cache-Control
  Cache-Control: public, max-age=0, no-cache
3 Likes

It used to have no-store. I have some response headers from July 2019 that include it.

Perhaps it was being applied via Akamai configuration, and then when the move to Cloudflare was made last September, it was silently dropped? AFAICT Boulder has never included the directive on its own.

I suppose since pretty much every response generated by Boulder includes a Replay-Nonce, a fix could be to just add no-store to this line here:

@jsha

Edit: wfe2, not wfe

Also, shouldn’t the spec say that any response containing a Replay-Nonce header must include the no-store directive, not just the ones for the newNonce resource? After all, the effect would be the same. Maybe worth an erratum?

2 Likes

Thanks for the report and the analysis! What you’ve both said makes sense and I’ve filed an issue to fix it: https://github.com/letsencrypt/boulder/issues/4727

2 Likes

I’m glad I’m not the only person who wondered that. I’m not sufficiently immersed in the minutiae of HTTP to be able to say for certain whether it’s necessary, but it certainly crossed my mind. One thing I considered was that new nonces need to be provided in POST responses and badNonce errors (and other errors), and IIRC responses to POSTs and 4xx/5xx errors aren’t supposed to be cached, and so perhaps it’s not a problem? As I said, though, I’m not enough a HTTP expert to be willing to make that call either way in an erratum.

Ahh, the one non-POST case I had in mind was for GET /directory.

But now that I checked more carefully, Boulder isn’t actually sending a nonce in those responses (nor should it, by the spec).

That only happened in ACME v1 - so you can ignore everything I wrote on the matter :stuck_out_tongue: .

(Edit: you can get one by HEAD /directory though, apparently).

So you can. How extremely curious, especially since the rest of the HEAD response appears entirely cromulent for a /directory request.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.