CVE-2020-11501: DTLS client hello contains a random value of all zeroes

Description of problem:

When using libcoap example client built with GnuTLS against a Californium + Scandium COAP Server the DTLS handshake can not be completed. We are using one-way authentication with x509 certificates (issued by Lets Encrypt via DNS01 ACME). Investigation of the Wireshark logs showed several issues on the client side (backed by GnuTLS):

• the first CLIENT_HELLO use a Random of 32 \0 bytes, Cookie field MUST be empty.
• CLIENT_HELLO should be retransmitted using same parameters + the cookie in HELLO_VERIFY, in the capture Random change all the time. (see https://tools.ietf.org/html/rfc6347#section-4.2.1)

Note that the libcoap example client with openssl as DTLS library can complete the handshake, as do the Californium Java client, and the go-coap client.

Version of gnutls used:

• GnuTLS: 3.6.9
• libcoap: 4.2.1

Distributor of gnutls (e.g., Ubuntu, Fedora, RHEL)

Ubuntu

How reproducible:

Build libcoap with GnuTLS following the instructions here: https://libcoap.net/install.html

Run:

./examples/coap-client -m get -v 9 "coaps://coap.blockbax.com"

Alternatively, inspect my Wireshark pcaps:

• Example failure libcoap-oneway-x509-gnutls.pcap
• Example success libcoap-oneway-x509-openssl-working.pcap

Actual results:

libcoap example client with GnuTLS as DTLS library ignores Hello Verify Requests from Server and keeps retrying.

Expected results:

libcoap example client iwth GnuTLS as DTLS library completes DTLS handshake succesfully similar to other clients.