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)
Build libcoap with GnuTLS following the instructions here: https://libcoap.net/install.html
./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
libcoap example client with GnuTLS as DTLS library ignores Hello Verify Requests from Server and keeps retrying.
libcoap example client iwth GnuTLS as DTLS library completes DTLS handshake succesfully similar to other clients.