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.