Nonce expiration


#1

Quick question - does nonce have an expiration period? Basically, once you’ve got nonce, is there a time period after which an attempt to use it will lead to “JWS has invalid anti-replay nonce” error?


#2

Maybe @jsha can answer that question.


#3

Nonces expire, but it’s not based on time, it’s based on consumption. Also any time Boulder’s frontend gets restarted, existing nonces are no longer valid. However, badNonce is very much a recoverable error, since it always includes a fresh nonce.

My recomendation would be: Don’t bother storing nonces on disk. Keep them in memory only for the lifetime of a process. However, in long-running processes, it’s fine to just use the most recent nonce you have, regardless of how old it is. But make sure to implement retries on badNonce errors.


Intermittent badNonce errors
Intermittent badNonce errors
#4

Ah, brilliant. So basically this particular response would contain a nonce header that just could be used to retry the last request. Correct?


#5

Yep, that’s exactly correct. Also, each successful response to a POST currently contains a nonce header. I would recommend that your app store all nonce headers that it sees for any request (up to a smallish maximum) and pull from that pool when it needs a nonce.


#6

Thanks, that explains it. I’d probably still pull the nonce for retry from the error though, rather than collecting nonces from success responses. As you pointed out, based on consumption or on boulder restart, whatever has been collected could become invalid (for example while you were waiting for your DNS to update).


#7

Sorry, I should have been clearer: I would prefer it if you collect nonces from success responses as well as failed responses. If you always trigger an error response in order to get a nonce, your client will send twice as many requests and use twice as much bandwidth as necessary. It may be small on a per-client basis, but across the whole service it adds up.


#8

Of course not :slight_smile: The idea of triggering errors to collect nonces would be rather … odd. Basically I was investigating a specific use case, related to a very long period of waiting before the challenge got checked. Thanks to your explanation, it seems that the best way to recover in that case is to continue with the nonce that comes back with an error. What I meant above regarding collection or saving nonces in the process is that it does not make much sense to collect any of them, since the frontend could have been restarted for example (apparently invalidating them all).


#9

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