DTLS cookie verification failing using built-in cookie write/verify

[MrSurly]

• Type: Question
• Priority: Minor

I'm trying to make DTLS work in MicroPython for the ESP32. I've been using dtls_server.c and dtls_client.c as my template. Making this work in MicroPython is rather involved because of the layers of abstraction involved.

The good news: It works!

The bad news: Hello Verify does not work

At the moment, I simply call mbedtls_ssl_conf_dtls_cookies with NULL for the callbacks to disable Hello Verify, and this works.

It doesn't work when I use mbedtls_ssl_cookie_write and mbedtls_ssl_cookie_check from library/ssl_cookie.c

I'm using the version of mbedtls (2.6.0) that's contained with the ESP IDF.

I traced it down to ssl_cookie.c line 219:

if( cookie_len != COOKIE_LEN )
    return( -1 );

After adding instrumentation, cookie_len is 0, and COOKIE_LEN is 32.

The actual question

Why is cookie_len zero?
And that's were I'm stuck.

My code

My relevant changes to the MicroPython SSL wrapper are embedded:

https://github.com/MrSurly/micropython-esp32/blob/dev-dtls/extmod/modussl_mbedtls.c#L206
https://github.com/MrSurly/micropython-esp32/blob/dev-dtls/extmod/modussl_mbedtls.c#L223

I should note that I'm using a transport id of "abcdef" (for mbedtls_ssl_set_client_transport_id) since I don't yet have IP/PORT available to the SSL wrapper. This is only for testing, of a single connection, and I don't think it's relevant, since it need only be unique to the client, per the docs. Yeah, there's a memory leak there with the malloc =)

[hanno-becker]

Hi @MrSurly,

thanks for your inquiry! Did you capture a network dump to see which packets are being exchanged? The first ClientHello is expected to have a cookie_len of zero, hence the server-side cookie verification would fail by expectation, and a HelloVerify with a valid cookie would be issued. Is that the case? If yes, the client should include that cookie in his second ClientHello, which would then have the expected cookie_len value.

Could you verify where your system's behavior deviates from the above expectation?

Regards,
Hanno

[MrSurly]

@hanno-arm Thanks for the info. I'll revisit this when higher-priority issues have been resolved.

I do know that handshake returns with MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED.

I'll re-enable debugging, and get a full log.

Packet sniffing will have to be via WiFi -- I'll look into how to do that.

[RonEld]

Hi @MrSurly
Is this issue still valid?
Please reopen with a followup, for further assistance.
Thanks!

[mbiuki]

I get the same behavior as described by #1124 (comment)
However, I am not sure how to resolve MBEDTLS_ERR_SSL_HELLO_VERIFY_REQUIRED problem. I am referencing https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/dtls_server.c in my DTLS server implementation.

See my Wireshark attached:
DTLS_server.zip

[gilles-peskine-arm]

@mbiuki For support questions, please post to the mailing list: https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls