I originally found this in version 1.0.1e, but this also appears to be present in the latest master branch of the git repository.
If a DTLS server has been configured to require a cookie exchange, it appears the server never retransmits the HelloVerifyRequest message if the client sends another ClientHello with sequence number zero and no cookie. But, this means that if the HelloVerifyRequest message from the server is lost (it's UDP, so anything can happen), the client will never be able to connect. Is this intentional behavior? I can imagine this may be an attempt to thwart a DoS attack, but it seems the attacker has to do as much work as the system under attack by resending the ClientHello again. I am attaching source code (in C) for a small (single source file) test program to reproduce this. The test program uses separate read and write datagram BIOs to simulate a lost UDP datagram. After the program sends the initial ClientHello and fails to read the HelloVerifyRequest, the user is prompted to press "enter." When the user does so, the program replaces the read BIO in the SSL object with the correct BIO and retries SSL_connect. In a wireshark trace, one can see that the server never resends the HelloVerifyRequest in reply. (Pass the server IP address and port as command line parameters.) I have tested this with "openssl s_server" running on localhost: % ./apps/openssl version OpenSSL 1.1.0-dev xx XXX xxxx % ./apps/openssl s_server -cert keycert.pem -accept 5555 -dtls1 Then: % test-lost-helloverifyrequest 127.0.0.1 5555 - Ken
test-lost-helloverifyrequest.c
Description: Binary data
_______________________________________________ openssl-bugs-mod mailing list [email protected] https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod
_______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
