More info on ssl_early_data security

[Sam Bull]

I'm looking at the RFC relating to 0-RTT, and trying to understand how ssl_early_data can be used safely.

If I understand correctly, the main replay issues are not an issue for idempotent actions. Therefore it should be safe to enable for static assets and any pages with fastcgi_cache enabled, etc.

However, it also talks about indirect attacks from a large number of replays, and says that a server "MUST ensure that it would accept 0-RTT for the same 0-RTT handshake at most once".

So, my question is: Does Nginx meet this last requirement? And, please add this information to the ssl_early_data documentation.

[Maxim Dounin]

No. Moreover, nginx ​explicitly disables a "security" mechanism in OpenSSL inspired by this particular quote, since this "security" mechanism effectively switches off SSL session reuse and makes it impossible to use early data (it only works with built-in session caching). With BoringSSL, there are no such mechanisms.

Note well that this requirement has nothing to do with security, and shouldn't be in the standard in the first place. If you want to limit possible resource usage, consider using existing limiting mechanisms available in nginx, such as ​limit_req and ​limit_conn.

If you have further question, please use ​support options available.

[Sam Bull]

So, something like this mentioned attack is unrelated?

"Exploiting cache timing behavior to discover the content of 0-RTT messages by replaying a 0-RTT message to a different cache node and then using a separate connection to measure request latency, to see if the two requests address the same resource."

[Maxim Dounin]

If such attacks are possible in your infrastructure, they cannot be mitigated by accepting a given 0-RTT handshake at most once by "any instance of" a server.