Topic: DTLS 1.0 "forced" instead of 1.2

I am writing an application that using TLS and DTLS.  I set it up to use DTLS v1.2 via wolfDTLSv1_2_client_method().  For testing purposes (in house), I created both a client and server side for the application and also tested it against the sample client and server test apps provided in WolfSSL (verifying handshake since application layer is obviously different).  All looked good.

Then I set up the client side of that application to talk to server side with a different implementation of DTLS.  Communication failed.  The reason for the communication failure was that the server side was dropping the ClientHello because it contained version 1.0 in the message.

I looked through the wolfSSL library (SendClientHello), and it initially does populate the record with the correct 1.2 version, but then has the following lines of code (within SendClientHello, internal.c):

#ifdef WOLFSSL_DTLS
        if (ssl->options.dtls) {
            DtlsRecordLayerHeader* rh = (DtlsRecordLayerHeader*)output;
            rh->pvMajor = DTLS_MAJOR;
            rh->pvMinor = DTLS_MINOR;
        }
#endif /* WOLFSSL_DTLS */

which will always hardcode the version to 1.0.

I don't see how this could be anything but a bug.  Is there something I'm not configuring correctly (build option?) so that this doesn't happen?
Should I be able to safety remove those lines of code?

Share

Re: DTLS 1.0 "forced" instead of 1.2

This was due to a misreading of RFC 6347 section 4.2.2. This has been recently fixed in our GitHub repository, commit 6d520e0.

Re: DTLS 1.0 "forced" instead of 1.2

Issue still isn't fixed.  Grabbed the latest out of Github and can still reproduce the issue.

Looks like the issue is that idx is != 0, so whatever offset its modifying isn't the correct one.

Share

Re: DTLS 1.0 "forced" instead of 1.2

Hi Michael,

It sounds like this issue has been fixed, can you confirm?

Thanks,
Chris