QUIC anti-replay is faked and insecure

[benh-debian]

QUIC 0-RTT requires anti-replay protection to be secure. This is currently being faked in tlshd by setting a callback function of tlshd_quic_server_anti_replay_db_add_func(), which always returns 0 (not a replay).

All of the current anti-replay initialisation should be removed until a real anti-replay callback is implemented. It appears to be optional and GnuTLS will disable 0-RTT if gnutls_anti_replay_enable() is not called.

[lxin]

@benh-debian gnutls_anti_replay_set_add_function() provides an option to enhance replay protection if the .db_add_func (e.g., tlshd_quic_server_anti_replay_db_add_func) is implemented properly. However, even if this function is left empty, gnutls still applies some basic replay detection.

For example, it records a start_time before the connection begins and sends a session ticket to the client from the server. During session resumption (a new connection), the server validates the ticket's creation time against this start_time:

https://github.com/gnutls/gnutls/blob/94e01a704f307a83ccb7799d1c2626f9635f2b5c/lib/tls13/anti_replay.c#L151

Currently, tlshd handles each handshake request in a new process rather than a thread. As a result, it cannot share the gnutls_anti_replay_t object across processes. This causes 0-RTT data to be automatically disabled, since _gnutls_anti_replay_check() fails validation in the absence of a shared anti-replay context. Therefore, there's no need to remove the anti-replay initialization manually.

To properly support 0-RTT data, we need to enable sharing of the gnutls_anti_replay_t object across processes in some way.

Thanks.

[chucklever]

Note that the handshake processes are not long-lived. Each child process exits as soon as the handshake is complete. tlshd children are unlikely to be the context in which session information is preserved.

But see PR 95: there is interest in adding support for TLS KeyUpdate, which also requires there to be some long-lived session context. I've asked the submitter to move that conversation to kernel-tls-handshake@ where you can chime in with whatever requirements QUIC 0-RTT might need.