[gnutls-devel] GnuTLS | Listening DTLS server responds with HELLO_VERIFY_REQUEST to most messages (#632)

[Development of GNU's TLS library]

New Issue was created.

Issue 632: https://gitlab.com/gnutls/gnutls/issues/632
Author:    Paul F.B.
Assignee:  

I am not sure if this is a bug or something intended. Analyzing models of the GnuTLS DTLS server implementation by [state learning](http://www.cs.ru.nl/~joeri/StateMachineInference.html), I noticed that the DTLS server will initially respond with HELLO_VERIFY_REQUEST to not only to CLIENT_HELLO messages, but also to most other messages. Attached is a Wireshark capture of GnuTLS v. 3.5.19 doing this for a FINISHED message, and actually completing the handshake, plus the model obtained (viewable via xdot, BTW I couldn't find much else wrong in it). This is reproducible also on the latest GnuTLS version.

The command for running the server is:
`gnutls-serv --udp --disable-client-cert --pskpasswd some_path_to_keys --port 20000 --priority NORMAL:+PSK:+SRP`

I was wondering if this was intended behavior. It seems weird, as the DTLS specification is quite clear about the flow of a handshake (CLIENT_HELLO/HELLO_VERIFY_REQUEST CLIENT_HELLO/SERVER_HELLO...). Weirder still, HELLO_VERIFY_REQUEST is sent also in response to ALERT messages. 

[gnutls_onehello_handshake.pcapng](/uploads/3316243dd059d5796db178cb3bdfcb31/gnutls_onehello_handshake.pcapng)
[gnutls.dot](/uploads/527dae5bd07038c5f81110bb86c8cc98/gnutls.dot)

-- 
Reply to this email directly or view it on GitLab: https://gitlab.com/gnutls/gnutls/issues/632
You're receiving this email because of your account on gitlab.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnupg.org/pipermail/gnutls-devel/attachments/20181129/e8263169/attachment-0001.html>