Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
I am using mbedtls_x509write_csr_set_subject_name API from mbedtls to set the subject name.
I wanted to set the arbitrary old value in my certificate for e.g.
ffeBgt9jDHhBwPDANgtT7R/1.3.6.1.4.1.37244.2.1=FFF2/1.3.6.1.4.1.37244.2.2=8001
In this case ffeBgt9jDHhBwPDANgtT7R is the CN
And 1.3.6.1.4.1.37244.2.1 is an arbitrary OID which has a value of FFF2 similar to the second arbitrary OID.
I am able to do this through openssl commands, but while doing it through mbedtls, when I pass it as a string then mbedtls considers the whole string as CN which Is not my intention.
Please fine the asn1 parsing of the CSR as below
CSR generated through mbedtls:
18:d=5 hl=2 l= 3 prim: OBJECT :commonName
23:d=5 hl=2 l= 76 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R/1.3.7.1.4.1.37466.2.1=FFF2+1.3.7.1.4.1.37466.2.2=8001
101:d=3 hl=2 l= 11 cons: SET
103:d=4 hl=2 l= 9 cons: SEQUENCE
Target CSR ( done thorough openssl):
14:d=4 hl=2 l= 29 cons: SEQUENCE
16:d=5 hl=2 l= 3 prim: OBJECT :commonName
21:d=5 hl=2 l= 22 prim: UTF8STRING :ffeBgt9jDHhBwPDANgtT7R
45:d=3 hl=2 l= 20 cons: SET
47:d=4 hl=2 l= 18 cons: SEQUENCE
49:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.1
61:d=5 hl=2 l= 4 prim: UTF8STRING :FFF2
67:d=3 hl=2 l= 20 cons: SET
69:d=4 hl=2 l= 18 cons: SEQUENCE
71:d=5 hl=2 l= 10 prim: OBJECT :1.3.7.1.4.1.37466.2.2
83:d=5 hl=2 l= 4 prim: UTF8STRING :8001
89:d=2 hl=2 l= 89 cons: SEQUENCE
91:d=3 hl=2 l= 19 cons: SEQUENCE
93:d=4 hl=2 l= 7 prim: OBJECT :id-ecPublicKey
102:d=4 hl=2 l= 8 prim: OBJECT :prime256v1
Am I missing something here? Do I need to provide the CN in a different way to get the intended result?
I found an open issue https://github.com/Mbed-TLS/mbedtls/issues/4886, could it be related to this?
Any help would be appreciated.
Thanks and Regards,
Aditya
Hi All,
Some websites crash MbedTLS, in
void mbedtls_ecp_point_free( mbedtls_ecp_point *pt )
{
if( pt == NULL )
return;
mbedtls_mpi_free( &( pt->X ) );
mbedtls_mpi_free( &( pt->Y ) );
mbedtls_mpi_free( &( pt->Z ) );
}
It crashes in the last function call of the three above.
Thread #1 [main] 1 [core: 0] (Suspended : Signal :
SIGTRAP:Trace/breakpoint trap)
HardFault_Handler() at stm32f4xx_it.c:103 0x8053c22
<signal handler called>() at 0xffffffed
0x3810180
mbedtls_ecp_point_free() at ecp.c:594 0x8029c7a
0x81030100
It crashes properly i.e. invalid opcodes etc.
There is a fair bit on google with others having gone down the same
road, never resolved.
One site which does it is socata.org but quite a few others do it.
Probably 10% of "major name" websites cause it to crash.
It may have been undiscovered for a long time, or ever, because most
MbedTLS clients are connecting to specific private servers only.
People aren't using it to connect to microsoft.com (which doesn't
actually crash but the handshake returns 0x2700 which can be
investigated).
There is a Windows build of MbedTLS (v2.16.2) which seems to work in
the crashing cases. Stepping through this in Cube IDE (32F417) it
looks like the crash is due to a buffer being filled with random
numbers. The guy working on this is contactable only on Monday
afternoons so I am a bit screwed :) He said he found something about
that buffer, or maybe a corrupted function pointer.
But as I said this issue has come up before according to numerous
online searches and maybe someone can recognise it.
Hardware AES is enabled but this occurs with software AES also. No
other 32F417 hardware crypto features are used, other than its random
number generator.
TLS is v2.16.2.
Thank you in advance for any pointers.
Peter
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Dec 5 at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
As usual, if anyone has any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hi All,
Mbed TLS is planning to move to a new code style by the end of this year. The proposed new style is currently being discussed in the GitHub pull request:
https://github.com/Mbed-TLS/mbedtls/pull/6591
If you have any feedback on this new style, or you think we should tweak it, feel free to comment on the pull request. We will take your thoughts into account when we decide on the final style.
Discussions will continue until the evening of THIS FRIDAY (UK time).
Many thanks,
David Horstmann for the Mbed TLS Team
Hi All,
A gentle reminder that the US-Europe timezone-friendly MBed TLS Tech forum
is next Monday at 4:30 PM UK time. Invite details can be found on the
online calendar here <https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org
Hello everyone,
We observed a strange behavior in the mbedTLS client, when client authentication is requested by the TLS server. This behavior was observed in the newer version 3.0.0 as well as in older versions.
The scenario is the following: The server selects a ciphersuite e.g. ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 and sends a CertificateRequest message that only includes the ecdsa_secp256r1_sha256 signature algorithm.
However, the mbedTLS client simply ignores the requested hash function and uses ecdsa_secp256r1_sha384 for the signature in the ClientVerify.
Then, the server complains since the signature does not match with the requested signature algorithm and sends a handshake failure.
It seems that mbedTLS does not store the requested signature algorithms/hash function from the CertificateRequest and always uses the hash function from the selected ciphersuite.
In the ssl_write_certificate_verify function, we find the following comment:
/*
* digitally-signed struct {
* opaque handshake_messages[handshake_messages_length];
* };
*
* Taking shortcut here. We assume that the server always allows the
* PRF Hash function and has sent it in the allowed signature
* algorithms list received in the Certificate Request message.
*
* Until we encounter a server that does not, we will take this
* shortcut.
*
* Reason: Otherwise we should have running hashes for SHA512 and
* SHA224 in order to satisfy 'weird' needs from the server
* side.
*/
Is this a known problem and is there any fix available?
Cheers,
Simon Nachtigall
Hi All,
A gentle reminder that the Asia-Europe timezone-friendly MBed TLS Tech
forum is next *Monday, Nov 7 at 10:00am UK time*. Invite details can be
found on the online calendar here
<https://www.trustedfirmware.org/meetings/>.
If you have any topics, please let Dave Rodgman, cc'd, know. :)
Best regards,
Don Harbin
TrustedFirmware Community Manager
don.harbin(a)linaro.org