[gnutls-devel] GnuTLS | DTLS handshake restarted by ClientHello using invalid message sequence numbers (#1233)
Read-only notification of GnuTLS library development activities
gnutls-devel at lists.gnutls.org
Wed May 12 19:35:53 CEST 2021
I opened a similar [issue for Scandium](https://github.com/eclipse/californium/issues/1620), which also exhibited this behavior. From the discussions I had there, it appears the DTLS 1.2 RFC may provide some ground for accepting ClientHello messages with increased message sequence numbers based on the [quote](https://www.rfc-editor.org/rfc/rfc6347.html#page-18):
> If a server receives a ClientHello with an invalid cookie, it SHOULD
> treat it the same as a ClientHello with no cookie. This avoids
> race/deadlock conditions if the client somehow gets a bad cookie
> (e.g., because the server changes its cookie signing key).
> Note to implementors: This may result in clients receiving multiple
> HelloVerifyRequest messages with different cookies. Clients SHOULD
> handle this by sending a new ClientHello with a cookie in response to
> the new HelloVerifyRequest.
If this is indeed the reason for accepting such ClientHellos, then I think the issue can be closed. I am leaving this issue open to to ensure the behavior is intended (a dev may close it if that is the case), as it does appear to be a bit of an edge case.
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/-/issues/1233#note_574085248
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gnutls-devel