mbedTLS version used is 2.14.0.
mbedTLS worked fine on i386 based 64-bit linux machine out of the box. Also, we could port same on a 32-bit processor, little endian arm (EABI5 v1) based linux machine.
With same configuration used in above machines, while trying to port mbedTLS on iRTOS, ARM9 based processor, 32-bit big endian RISC architecture, it fails in write certificate verify after calc verify sha256 stage in client state:9.
We also used to get problem after client state:3, where alert with error 48 i.e. unknown_ca was being generated, but we could overcome it by setting hs_authmode as VERIFY_OPTIONAL.
Hi @kinani
Thank you fro reporting this!
From your description, it sounds to me that there is some sort of issue in 32-bit Big Endian architecture, probably in the rsa module.
This obviously requires further investigation.
We also used to get problem after client state:3, where alert with error 48 i.e. unknown_ca was being generated, but we could overcome it by setting hs_authmode as VERIFY_OPTIONAL.
This should be done for debug purposes only. This is not secure, as you are ignoring the certificate verification result.
Note that we aim to be multi platform and multi architecture, but issues may arise.
Does this reproduce with older versions of Mbed TLS, such as 2.7 LTS branch?
Does this reproduce with ECC based certificates?
Regards,
Mbed TLS Team member
Ron
Appreciate your quick response!
With some more debugging we figured some memory related problem in our OS Adaptation layer for the platform. Fixing that did complete the handshake without even setting hs_authmode to VERIFY_OPTIONAL. Thanks for the info.
Because of some performance concerns, we accept out of order packets from transport layer, which seems to generate a fatal alert saying bad_record_mac (20).
If we don’t do changes, system runs fine, but we need those changes to perform better. So, my question is whether we need MAC verification or can it be skipped. If yes, can you please guide how to go ahead.
Hi Kartik,
In order to have a secure transport, the messages are encrypted and authenticated ( Depending on the ciphersuite negotiated )
Since the negotiated ciphersuite is TLS-RSA-WITH-AES-128-CBC-SHA, have you considered using an AEAD based ciphersuite?
Does your platform have HW acceleration?
We forced this ciphersuite thinking it will take lesser processing (due to machine’s performance constraints).
So what we want is a ciphersuite which allows us to have out-of-order transport packets and still be low on computations. Also, our platform doesn’t support hardware accelerations. Can we configure mbedtls to do this?
AEAD based ciphersuites are better in terms of security. Have you tried other ciphersuites?
Have you tried ECP based ciphersuites instead of RSA ones, as this reduces the key size with similar security strength?
Also, our platform doesn’t support hardware accelerations. Can we configure mbedtls to do this?
You can configure Mbed TLS to use alternative implementations, as described in this article, however you will need a hw accelerator in your target.
Regards
Thanks for the quick response.
We did try TLS_RSA_WITH_AES_128_GCM_SHA256 but to no avail.
We don’t have much option but to use TLS-RSA-WITH-AES-128-CBC-SHA
ciphersuite.
For experimental purpose, can you please guide to disable the MAC verification through config or code.?
Hi Kartik,
Unfortunately, that is not really possible…
Part of the TLS ciphersuites is having the packets authinticated in some way, either by MAC or AEAD.
Even if we disbale on your peer the mac processing, the remote peer will still verify, and have MAC failed, sending you a fatal alert.
I should have asked this earlier, but are you negotiating a TLS or DTLS handshake?
Regards
The handshake is successful but after some packets are successfully decrypted, we get -29056 (0x7180) i.e. Verification of the message MAC failed.
Let the remote peer verify the MAC, we just want to disable the MAC check at our end i.e. client end. Can you please let us know which part of code is responsible for MAC verification, disabling which could skip MAC verification.
Hi Martik,
For the benefit of the community, it is better to start a new thread if there is a new issue. Please don’t change subject, as it might confuse other users.
As you can see n ssl_tls.c in the function ssl_decrypt_buf, you will see the MAC calculated for your ciphersuite, however, if you want to disable MAC, you can disable TLS altogether, as you lose security.
If you are using TLS, you shouldn’t be getting out of order messages, and there is probably some internal issue causing you this error.
Have you tried looking at other related posts, for example:
Have you changed value of MBEDTLS_SSL_MAX_CONTENT_LEN or MBEDTLS_SSL_IN_CONTENT_LEN ?
If so, when the server sends you a message bigger than the value, and you are reading only the modified value, the calulated mac would differ between the two peers as well.
We were getting in-order packets from transport but we were splitting them in two threads and then giving to mbedTLS, may be that caused the issue. Sending them in single thread context works fine.
