Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1718 closed enhancement (invalid)

More info on ssl_early_data security

Reported by: Sam Bull Owned by:
Priority: minor Milestone:
Component: documentation Version: 1.15.x
Keywords: Cc:
uname -a:
nginx -V: nginx


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.

Change History (3)

comment:1 by Maxim Dounin, 5 years ago

Resolution: invalid
Status: newclosed

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.

comment:2 by Sam Bull, 5 years ago

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."

comment:3 by Maxim Dounin, 5 years ago

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.

Note: See TracTickets for help on using tickets.