Arm Mbed and Pelion device management support forum

Handshake timeout, 2.16.3 versus 2.14.1, on missing Client Key Usage

I have written TM4C bare metal (no RTOS) firmware that works fine with mbedTLS 2.14.1, and I have a test case where a Client certificate is sent without the appropriate Client Key Usage. Using 2.14.1, the handshake completes, but is rejected due to the missing Key Usage. So far, all is behaving as expected.

I have now upgraded to the mbedTLS 2.16.3 release, and this test case is failing. The symptom is that the handshake times out, and the python test client doesn’t see the expected SSL failure it was receiving before.

As part of the upgrade, all existing config.h settings were merged into the new config.h, particularly important things like MBEDTLS_X509_CHECK_KEY_USAGE and MBEDTLS_X509_CHECK_EXTENDED_KEY_USAGE.

Does anyone have suggestions as to what might have changed? I doubt this is a bug in 2.16.3 - I assume that client key usage checking is fully functional. Perhaps there is a related setting that I missed that is somehow overriding this feature. Any clues where I should look, or how to debug this?

Brian

HI Brian,
It is not entirely clear what your test case is.
Does the certificate have a key usage extension, but without the relevant usage?
Does it have an invalid extension? An empty extension?
Could you please show the relevant certificate?
Using a debugger, could you point to where your device is stuck?

Looking at the changeLog, the only changes done related to key usage were on PR 2429, however it is related to certificate writing, and not verifying.
Have you tried checking other versions in between, to check which version introduced this timeout?
Regards,
Mbed TLS Support
Ron

The certificate is missing the Extended Key Usage extension.
There is no invalid extension.
I’m new here, and I don’t know how to attach the certificate as a .pem or .zip

I was able to reproduce this with the 2.16.0 release.

However, it’s worth pointing out that my test case passes in isolation, and also on some of our test fixtures, so I’m not entirely clear on where to place the blame. In particular, when I run on a system connected to a debugger, I cannot reproduce the issue, so the timeout may not be due to mbedTLS at all.

I’m mostly here, starting this thread, to make sure that I haven’t overlooked an obvious error in the 2.16.x release source that others have already found.

I will continue trying to narrow down the cause.

Thanks @madronalabsb for the information

I’m new here, and I don’t know how to attach the certificate as a .pem or .zip

No need to upload, you can just paste the contents of the certificate in a post, as a code block.

Mbed TLS logs would also help.

I couldn’t find anything obvious related to extended key usage, that was added in the 2.16.x branch.
The extended key usage is not mandatory, so if it is missing, there shouldn’t be a failure in the handshake, so I am not sure what your test case checks related to this.
Regards

When MBEDTLS_X509_CHECK_KEY_USAGE and MBEDTLS_CHECK_EXTENDED_KEY_USAGE are defined, the mbedTLS server code must report some kind of error to the client, because our python mTLS client library sees that the mbedTLS 2.14.1 server has rejected the certificate. The handshake itself doesn’t fail, because it reports the error correctly.

Changing to 2.16.x makes the python test fail in some cases, but not all, and I haven’t been able to catch it failing in a situation where I can log the error or step through the code. It’s entirely possible that the problem is entirely on the python client side. I will keep digging into the problem, and will hopefully be able to reproduce it under conditions where I can gather more information.

Thank you for the response so far,

Brian

-----BEGIN CERTIFICATE-----
MIIC9zCCAd+gAwIBAgIRAPz2lM1rMfHq3NnLlwAOTBowDQYJKoZIhvcNAQELBQAw
JzElMCMGA1UEAxMcQzJST1QgY2xpZW50IGludGVybWVkaWF0ZSBDQTAeFw0xOTA3
MjQyMDAyMThaFw0yMDA3MjMyMDAyMThaMCIxIDAeBgNVBAMTF0MyUk9UIGNsaWVu
dCAoZm9yIEhvUFMpMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0xLy
Xb0/csFW8n+tkQwl0qWTyf0ASUSKkyKxjkd0MD0UUlG2HTzlMmKCpfvU0t6IqmhF
90iasMqlpPd9ilgGT4gTMzVubzm6Fu9qGVkY9+jCbrS2tF7Go2NWWKLwLu9rIzaX
fTP5OQ3KmoXn0aKd8yZwhVDE9tWAhuUTzayUVY1Z8sKNQUfCDm3XbFOWmDTvRSk0
Iq51TQT/kv315WbcuL0g/VpR/mujbFsxdcdcCCKQm5kaxDhzaWGOtXdeBzKgGZy1
G8taUt5f75SMk/hKGxjUvM/wBCJwgOd5wGHorJaHyVwtcNINiRiizTBPgQ3FV999
VW5If8fir8Yd/uAGJQIDAQABoyMwITAfBgNVHSMEGDAWgBQcEMIMN0Rfmss2fgG7
9naeOrtaYDANBgkqhkiG9w0BAQsFAAOCAQEAW1BIf7lMy8Y+aDRR3L7SViUUHDec
YpbGMzA9xwvNJTdV7HvefqQErzWylnQVYY/6+JFZ0WT5np4FXA+4hgZThXSojJg/
h1W0ATgOwexMK8U6NU1nXWLWtsd3MlgbA0TloqVtiRumgDWzgJE9UVriWwsQNrsf
0Er41zJho31Dh5KCWoHWLVPrnAaywcGd/QDNomxiCfnzyWLQOrFN1XIvDqVZGB7o
S4SzCQI9iddik8T1E4zrNwlC2jDr/xYo/8qmt21sAtZSBxYDrKvms6YXidHQaSEq
dUftXQrBmZSQXODEdP3LSNt+cvvE2P4OuCVQ0rUqEin7He8XrZCokHOuHw==
-----END CERTIFICATE-----

Update: mbedTLS 2.16.x is reporting error -0x0050, MBEDTLS_ERR_NET_CONN_RESET Connection was reset by peer.
In part, this suggests that the python test client is causing the handshake to fail. I’m not sure why the behavior would change, though, and the client is even able to pass the test in isolation - just not when run in a large batch.

This is looking more and more like a python mTLS library issue. It merely seems to be the case that something that changed between 2.14.x and 2.16.x has triggered the issue.

I will keep looking into this, but so far nothing exactly points to an error in mbedTLS 2.16.x