[openssl-dev] [openssl.org #4025] Bug? DTLS server does not respond if HelloVerifyRequest message lost

[Ken Ballou via RT]

I'm sorry if I did not explain myself well.

The message flow I observed and am trying to describe is:

ClientHello ---------------------->
                            x----------------- HelloVerifyRequest
ClientHello ---------------------->
ClientHello ---------------------->
ClientHello ---------------------->
ClientHello ---------------------->
(and the sound of crickets chirping on the server side is deafening).

I do understand that the server does not RETRANSMIT the 
HelloVerifyRequest (and I do understand the reason for that).  What I am 
describing is a failure to RESPOND to a retransmitted ClientHello.

                     - Ken

On 8/29/2015 5:10 AM, Michael Tüxen via RT wrote:
>> On 28 Aug 2015, at 22:52, Ken Ballou via RT <rt at openssl.org> wrote:
>>
>> 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.
> The server isn't retransmitting the HelloVerifyRequest message, the client
> should retransmit the ClientHello. See
> https://tools.ietf.org/html/rfc6347#section-3.2.1
>
> Best regards
> Michael
>> 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>_______________________________________________
>> openssl-bugs-mod mailing list
>> openssl-bugs-mod at openssl.org
>> https://mta.openssl.org/mailman/listinfo/openssl-bugs-mod_______________________________________________
>> openssl-dev mailing list
>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev
>