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?
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’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.
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
It looks like this might have been due to a loss of optimization settings on a couple of source files in our mbedTLS build (Code Composer Studio). I’ll report back if I can get details from other team members.
Unfortunately, the fix is unknown.
I tried removing the optimizations on bignum.c and rsa.c, but our test still passes. This tells me that changes have been made to the test suite that “fixed” the issue.
I suppose we’ll never know why this one test failed temporarily.
The good news is that we’re using mbedTLS 2.16.3 now with no errors in our test suite.
Thanks to everyone who tried to help isolate this.
