Hi,
I must be missing something obvious but my code (on an ESP32) fails to
accept an incoming connection.
I tried the same certificate on an ESP32 sample, and it appears to work
there.
Does anyone have a clue where to look next ?
Danny
I (16:06:51.481) esp_https_server: performing session handshake
E (16:06:51.483) x509_crt: x509_crt_parse_der_core -> 0x2180
E (16:06:51.484) esp_tls_mbedtls: set_pki_context: public_cert
0x3ffdb924, len 5750 -> ret 0x2180
E (16:06:51.493) esp-tls-mbedtls: mbedtls_x509_crt_parse returned -0x2180
E (16:06:51.501) esp-tls-mbedtls: Failed to set server pki context
E (16:06:51.508) esp-tls-mbedtls: Failed to set server configurations
E (16:06:51.515) esp-tls-mbedtls: create_ssl_handle failed
E (16:06:51.521) esp_https_server: esp_tls_create_server_session failed
W (16:06:51.528) httpd: httpd_accept_conn: session creation failed
W (16:06:51.538) httpd: httpd_server: error accepting new connection
--
Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info
Hello everyone,
I am currently evaluating SSL with a local server and an STM32 device. I'm
unable to figure out why the decryption fails with CCM as the cipher suite.
FYI: I am using MbedTLS *v2.14.1.*
*Setup*:
I'm using *x86 local server* with *STM32* device as a client.
Here is what happens-
1. Software CCM implementation on the client:
When I use the *software* implementation of the CCM. Handshake and
decryption is *successful*. Therefore, I can stream
the data from STM32 and read it on the local server.
2. Hardware CCM implementation with MBEDTLS_CCM_ALT:
I have used ccm_alt.c provided from STM32Cube v1.9.0. Here, the
handshake is successful. But *decrypting* the
message *fails*.
The errors are:
ssl_decrypt_buf() returned -29056 (-0x7180)
mbedtls_ssl_read_record() returned -29056 (-0x7180)
Checks performed:
- Same certificates are used for SW and HW implementations.
- CCM self test returns '0' for both HW and SW CCM implementations.
- I have reserved enough heap, no memory issues.
Please find all the necessary data in the attachment provided. I have added
the logs from the server and the client. I have added the certificates and
the code files as well.
It would be of great help if somebody could point at what might be going
wrong.
Thank you!
Best regards,
Navin
Hi Shudong,
Mbed TLS currently does not provide EdDSA. The contribution by @aurel32 is a first step in this direction. The work leading up to a fully functional EdDSA implementation is tracked here:
https://github.com/ARMmbed/mbedtls/projects/2#column-11150355
Kind regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Shudong Zhang via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Wednesday, 30 June 2021 at 07:28
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Is the a version that can use the EdDSA signature algorithm currently?
Hello,
I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question?
Thanks and kind regards,
Shudong
Hello,
I want to use EdDSA signature algorithm, but I did’t find API for it in 2.26.0.Then I searched in the issue of Github and I found @aurel32 contributed some code about ed25519.But I am still not sure whether there are any versions under development that provide interface functions for EdDSA signature algorithm. Can someone help me answer my question?
Thanks and kind regards,
Shudong
Hi,
I have an ACME client library for esp32, and I try to extend it to
support multiple host names. First step is to include alternate names in
the CSR.
After I tried the ARMmbed issues forum, I was pointed to this list.
My code is in
http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…
<http://svn.code.sf.net/p/esp32-acme-client/code/trunk/libraries/acmeclient/…>
(see function Acme::CreateAltUrlList) , the function below is an attempt
to do what I described, but doesn't work.
Can anyone help ?
Danny
int Acme::CreateAltUrlList(mbedtls_x509write_csr req) {
int l = 20;
int ret;
for (int i=0; alt_urls[i]; i++) {
l += strlen(alt_urls[i]) + 20;
}
unsigned char *buf = (unsigned char *)malloc(l), *p = buf + l;
int len = 0;
for (int i=0; alt_urls[i]; i++) {
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_raw_buffer(&p, buf, (const
unsigned char *)alt_urls[i], strlen(alt_urls[i])));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf,
strlen(alt_urls[i])));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf,
MBEDTLS_ASN1_CONTEXT_SPECIFIC | 2));
}
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_len(&p, buf, len));
MBEDTLS_ASN1_CHK_ADD(len, mbedtls_asn1_write_tag(&p, buf,
MBEDTLS_ASN1_CONSTRUCTED | MBEDTLS_ASN1_SEQUENCE));
if ((ret = mbedtls_x509write_csr_set_extension(&req,
MBEDTLS_OID_SUBJECT_ALT_NAME,
MBEDTLS_OID_SIZE(MBEDTLS_OID_SUBJECT_ALT_NAME),
(const unsigned char *)p, len)) != 0) {
char errbuf[80];
mbedtls_strerror(ret, errbuf, sizeof(errbuf));
ESP_LOGE(acme_tag, "%s: mbedtls_x509write_csr_set_extension failed %s
(0x%04x)", *__FUNCTION__*, errbuf, -ret);
}
free(buf);
ESP_LOGD(acme_tag, "%s: ret %d", *__FUNCTION*__, ret);
return ret;
}
--
Danny Backx - dannybackx(a)telenet.be - http://danny.backx.info
Hi David,
Archive can be found here
https://lists.trustedfirmware.org/pipermail/mbed-tls/https://lists.trustedfirmware.org/pipermail/psa-crypto/
Regards,
Shebu
-----Original Message-----
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> On Behalf Of David Higton via mbed-tls
Sent: Friday, June 25, 2021 2:51 PM
To: mbed-tls(a)lists.trustedfirmware.org
Subject: [mbed-tls] List archive?
Hi everybody,
I've just joined the list. The first thing I did was to try to find an archive of list postings, but I haven't found one. Is there one, and, if so, where do I find it?
The information may have been staring me in the face; if that's the case, I apologise.
David
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi everybody,
I've just joined the list. The first thing I did was to try to find an
archive of list postings, but I haven't found one. Is there one, and,
if so, where do I find it?
The information may have been staring me in the face; if that's the
case, I apologise.
David
Hi Anasasija,
Mbed TLS is entirely agnostic of the communication channel or protocol. You can configure it to use any underlying layer, like TCP, UDP or even just a local buffer.
That said, we have a module that makes it more convenient to use Mbed TLS with TCP (or UDP) on common platforms:
https://github.com/ARMmbed/mbedtls/blob/development/include/mbedtls/net_soc…
You can see an example for using the module in several sample applications, for example:
https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_client… and
https://github.com/ARMmbed/mbedtls/blob/development/programs/ssl/ssl_server…
Kind regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of 1637062--- via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Friday, 25 June 2021 at 09:27
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] Is TCP integrated in mbed-TLS?
Hello,
I am a Student and for my bachelor thesis I am working on a tool that
is able to detect whether a server is vulnerable regarding
Bleichenbacher's attack or not, testing multiple side channels.
For this I am looking for a TLS implementation that has the TCP
protocol integrated and generates the TCP messages.
I was wondering if mbed-tls has the TCP integrated in the
implementation or not.
If so, I could make use of this information, too.
Thanks and kind regards,
Anastasija
--
mbed-tls mailing list
mbed-tls(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/mbed-tls
Hi Lijin,
It still can be the endianness of the keys. If the key is reversed, there won’t be any discernible pattern or relationship between the derived secrets.
Regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of T V LIJIN (EXT) via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Friday, 25 June 2021 at 09:15
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: Re: [mbed-tls] mbed-tls Digest, Vol 16, Issue 12
Hello,
We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness.
Could you please confirm that the code used for ECDHE key exchange is proper?
SHARED_SECRET (Computed on Client):
11 36 F7 DB 2B 14 BB 86
1C A0 FC DF 6D 4D 17 70
BE 4F D8 58 C2 11 67 10
42 D7 47 EB 14 4B 10 5E
SHARED_SECRET(Computed on Sever):
c6 96 d9 f0 ec 37 be 9e
1a 60 a4 5f 88 f2 13 d3
bb 98 15 3f 3b d9 81 37
c6 10 12 85 e5 8b 49 16
Thanks,
LIJIN T V
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org>
Sent: Friday, June 25, 2021 4:52 AM
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: mbed-tls Digest, Vol 16, Issue 12
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
or, via email, send a message with subject or body 'help' to
mbed-tls-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
mbed-tls-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of mbed-tls digest..."
Today's Topics:
1. ECDHE Shared Secret is computed differently (T V LIJIN (EXT))
2. Re: ECDHE Shared Secret is computed differently (Brian D.)
3. How does the bignum.c works? (Shariful Alam)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jun 2021 13:35:03 +0000
From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com>
To: "mbed-tls(a)lists.trustedfirmware.org"
<mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] ECDHE Shared Secret is computed differently
Message-ID:
<AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
We have tested the same source code on Visual studio and found working.
I have attached the source files
Could you please comment on why the computed shared secret are different on both the ends?
Thanks,
LIJIN T V
Hello,
I am a Student and for my bachelor thesis I am working on a tool that
is able to detect whether a server is vulnerable regarding
Bleichenbacher's attack or not, testing multiple side channels.
For this I am looking for a TLS implementation that has the TCP
protocol integrated and generates the TCP messages.
I was wondering if mbed-tls has the TCP integrated in the
implementation or not.
If so, I could make use of this information, too.
Thanks and kind regards,
Anastasija
Hello,
We couldn't see word swap in the output from both the end. Issue doesn't look related to the endianness.
Could you please confirm that the code used for ECDHE key exchange is proper?
SHARED_SECRET (Computed on Client):
11 36 F7 DB 2B 14 BB 86
1C A0 FC DF 6D 4D 17 70
BE 4F D8 58 C2 11 67 10
42 D7 47 EB 14 4B 10 5E
SHARED_SECRET(Computed on Sever):
c6 96 d9 f0 ec 37 be 9e
1a 60 a4 5f 88 f2 13 d3
bb 98 15 3f 3b d9 81 37
c6 10 12 85 e5 8b 49 16
Thanks,
LIJIN T V
________________________________
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of mbed-tls-request(a)lists.trustedfirmware.org <mbed-tls-request(a)lists.trustedfirmware.org>
Sent: Friday, June 25, 2021 4:52 AM
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: mbed-tls Digest, Vol 16, Issue 12
This message is from an external sender. Be cautious, especially with links and attachments.
Send mbed-tls mailing list submissions to
mbed-tls(a)lists.trustedfirmware.org
To subscribe or unsubscribe via the World Wide Web, visit
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
or, via email, send a message with subject or body 'help' to
mbed-tls-request(a)lists.trustedfirmware.org
You can reach the person managing the list at
mbed-tls-owner(a)lists.trustedfirmware.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of mbed-tls digest..."
Today's Topics:
1. ECDHE Shared Secret is computed differently (T V LIJIN (EXT))
2. Re: ECDHE Shared Secret is computed differently (Brian D.)
3. How does the bignum.c works? (Shariful Alam)
----------------------------------------------------------------------
Message: 1
Date: Thu, 24 Jun 2021 13:35:03 +0000
From: "T V LIJIN (EXT)" <lijin.tv(a)kone.com>
To: "mbed-tls(a)lists.trustedfirmware.org"
<mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] ECDHE Shared Secret is computed differently
Message-ID:
<AS8PR07MB8006A77D2451AD93FAFDA3D8FE079(a)AS8PR07MB8006.eurprd07.prod.outlook.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
We have tested the same source code on Visual studio and found working.
I have attached the source files
Could you please comment on why the computed shared secret are different on both the ends?
Thanks,
LIJIN T V
Hello,
Can someone please briefly explain how does the bignum.c library works in
terms of RSA? I understand that this is too broad a question to ask. but If
someone can briefly explain the basic working mechanism it will be a great
help.
Thanks,
Shariful
Hi Linjin,
I am not part of the mbed-tls staff but I developed a lot with mbed library and I had your same problem. Try to check the byte order, I had issues when computing the shared secret because I had the little endian from the other side but mbed uses big endian.
Try to do a quick test and this could resolve your problem, let me know!
Bye,
Brian
24 giu 2021, 15:35 da mbed-tls(a)lists.trustedfirmware.org:
> Hello ,
> We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
> Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
> We have tested the same source code on Visual studio and found working.
> I have attached the source files
>
> Could you please comment on why the computed shared secret are different on both the ends?
>
> Thanks,
> LIJIN T V
>
Hello ,
We are trying to perform an ECDHE key exchange between two devices running on different platforms.[one on Linux and another on RTOS]
Both the devices use the same code to compute the ECDHE shared secret. The peer public parameters are exchanged in the base64 format and passed to the functions correctly , but the final shared secret computed seems to be different on both ends.
We have tested the same source code on Visual studio and found working.
I have attached the source files
Could you please comment on why the computed shared secret are different on both the ends?
Thanks,
LIJIN T V
Hi Andrey,
Thank you for your interest in Mbed TLS! In general we welcome
contributions to the project. Unfortunately, our limiting factor is
bandwidth for review. In 2021 the Mbed TLS team has grown, so we have
more time for reviews, but we are still struggling to catch up with the
large backlog.
There is already an old attempt to add unencrypted PKCS#8 writing
support (https://github.com/ARMmbed/mbedtls/issues/1695
<https://github.com/ARMmbed/mbedtls/issues/1695>). There is a long
pending request for encrypted PKCS#8 writing support
(https://github.com/ARMmbed/mbedtls/issues/1372
<https://github.com/ARMmbed/mbedtls/issues/1372>) but I'm not aware of
any prior implementation.
We would be glad to have your contribution, but I must be honest and say
it might take us several months to get around to it.
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 09/06/2021 22:46, Андрей Макаров via mbed-tls wrote:
> Recently I used mbedtls library in my working project. In accordance
> with the needs of the project, I added some functions to mbedtls for
> saving and loading keys in plain and encrypted pem and der forms.
> The changes are still raw and should be brought up to pull request
> requirements - there are no tests, since the functions tested as part
> of a working project which uses mbedtls. I can, over time, finalize
> the changes to a pull request, but it will take some time and effort
> that you don't want to waste unnecessarily — this will have to be done
> at my home time.
> If there is an interest for this work, then I will try to do it, but
> if few people need it or do not coincide with the general direction of
> development of the project, then I would not bother.
> To be done: 1) added mbedtls_pk_write_key_pkcs8_der() write
> non-encrypted pkcs8 der key 2) added mbedtls_pk_write_key_pkcs8_pem()
> write non-encrypted pkcs8 pem key 3) added
> mbedtls_pk_write_key_encrypted_pem() write legacy encryped pem file
> with DEK-Info header 4) added
> mbedtls_pk_write_key_pkcs8_encrypted_der() write to encrypted pkcs8
> der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported 5) added
> mbedtls_pk_write_key_pkcs8_encrypted_pem() same as above but pem key
> 6) changed mbedtls_pem_read_buffer() which reads legacy encrypted pem
> formats (with DEK-Info header) now it uses mbedtls_cipher_… functions
> which allow to use any supported cipher rather than four enforced (was
> limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc) 7)
> changed pk_parse_key_pkcs8_encrypted_der() 7.1) added pkcs5 pbes1
> support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC
> (pbeWithSHA1AndDES-CBC) 7.2) changed pkcs12 pbe (use same cipher for
> all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC),
> SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128
> (pbeWithSHA1And128BitRC4); (the special
> mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed)
> 7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC
> ciphers Some «preview» is available at fork
> https://github.com/loafer-mka/mbedtls
> <https://github.com/loafer-mka/mbedtls>, branch ‘dev_clean’ Of course,
> many changes relate to obsolete formats, and may be undesirable … also
> I do not touch PSK at all.
> Please, give me some feedback — try to finish this with tests, pull
> request, etc or not. ----------- Regards, Andrey
>
Just finishing off this thread:
The issue appeared due to an invalid pointer access else where in the
application that coincided with the mbedtls_ssl_set_bio function.
Working on resolution now.
Thanks for all the help, pointers & hints from the list!
On 2021-06-08 2:27 p.m., Ron Eggler via mbed-tls wrote:
>
> Yes, there's some kind of "memory magic" going on here:
>
> The task got terminated due to "Load from invalid memory"
>
> and I see:
>
> |Instruction at 0x6310604d is trying to load data at 0x4, which is an
> invalid memory area. You are probably dereferencing a NULL pointer.|
>
> |and i got some trace back addresses that point to:|
>
> *
>
> mbedtls_aes_crypt_ecb
>
> *
>
> mbedtls_ctr_drbg_random_with_add
>
> *
>
> mbedtls_ssl_handshake_step
>
> *
>
> mbedtls_ssl_handshake
>
>
> ||
>
> On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote:
>> Hi Ron,
>>
>> This behavior can't be explained by the library code and the code you
>> posted alone. There has to be something wrong elsewhere.
>>
>> Check that you aren't exceeding a limitation such as the stack size or
>> the size of executable and data sections. If it can be an issue on your
>> platform, check that load addresses are correct and sections don't
>> overlap. Make sure there's no overlap with any device memory mapping either.
>>
>> Make sure that the whole binary is compiled with consistent settings.
>> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
>> configuration, so make sure that there's a single copy of
>> mbedtls/config.h and both Mbed TLS itself and your application were
>> built against that copy. The layout of mbedtls_ssl_context can also be
>> influenced by compiler settings on some platforms (e.g. structure
>> packing options), so make sure those are consistent across your build.
>>
>> That's all I can think of for now. It may help to add a lot of printf
>> debugging with %p on various addresses, and compare these addresses with
>> what you know about memory mappings on that platform. Good luck!
>>
>
Recently I used mbedtls library in my working project.
In accordance with the needs of the project, I added some functions to mbedtls
for saving and loading keys in plain and encrypted pem and der forms.
The changes are still raw and should be brought up to pull request requirements - there
are no tests, since the functions tested as part of a working project which uses mbedtls.
I can, over time, finalize the changes to a pull request, but it will take some time and
effort that you don't want to waste unnecessarily — this will have to be done at my home time.
If there is an interest for this work, then I will try to do it, but if few people need
it or do not coincide with the general direction of development of the project, then I
would not bother.
To be done:
1) added mbedtls_pk_write_key_pkcs8_der()
write non-encrypted pkcs8 der key
2) added mbedtls_pk_write_key_pkcs8_pem()
write non-encrypted pkcs8 pem key
3) added mbedtls_pk_write_key_encrypted_pem()
write legacy encryped pem file with DEK-Info header
4) added mbedtls_pk_write_key_pkcs8_encrypted_der()
write to encrypted pkcs8 der key; pkcs5 pbes1, pkcs12 and pbes2 schemes are supported
5) added mbedtls_pk_write_key_pkcs8_encrypted_pem()
same as above but pem key
6) changed mbedtls_pem_read_buffer()
which reads legacy encrypted pem formats (with DEK-Info header)
now it uses mbedtls_cipher_… functions which allow to use any supported cipher rather than four
enforced (was limited to des-cbc, des-ede3-cbc, ars-128-cbc and aes-256-cbc)
7) changed pk_parse_key_pkcs8_encrypted_der()
7.1) added pkcs5 pbes1 support MD5-DES-CB CpbeWithMD5AndDES-CBC) and SHA1-DES-CBC (pbeWithSHA1AndDES-CBC)
7.2) changed pkcs12 pbe (use same cipher for all SHA1-DES2-EDE-CBC (pbeWithSHAAnd2-KeyTripleDES-CBC),
SHA1-DES3-EDE-CBC (pbeWithSHAAnd3-KeyTripleDES-CBC) and SHA1-RC4-128 (pbeWithSHA1And128BitRC4);
(the special mbedtls_pkcs12_pbe_sha1_rc4_128() is not used now and may be removed)
7.3) changed pkcs5 pbes2 support: added AES-128-CBC and AES-256-CBC ciphers
Some «preview» is available at fork https://github.com/loafer-mka/mbedtls, branch ‘dev_clean’
Of course, many changes relate to obsolete formats, and may be undesirable … also I do not touch PSK at all.
Please, give me some feedback — try to finish this with tests, pull request, etc or not.
-----------
Regards,
Andrey
Dear All,
I am having multiple queries regarding session resumption and renegotiation.
I understand that normally session resumption is used at every new
connection and session renegotiation is used on live connection.
Our domain standards recommends to use session resumption to change session
key ( or keyblock
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
) at regular intervals without closing connection and session renegotiation
to change master key at regular interval using session renegotiation. This
is due to the fact that the connection will be long lasting.
Query 1:
I understand that mbedtls currently does not support session resumption on
live connection. Is there any plan to include it in the near future? ( may
be similar to openssl SSL_renegotiate_abbreviated api)
Query 3:
If the application wants to know if session renegotiation has happened as
part of mbedtls_tls_read and mbedtls_tls_write, is there any callback/API
for that?
--> I am only thinking of using session->start comparison in application to
know if session is renegotiated. Is there any better method?
Query 4:
Our requirement is to understand and log security event in case failure due
to certificate verification fail (revoked/expired etc..) currently we use
mbedtls_ssl_get_verify_result api for same
There is a case when certificate becomes expired/revoked while doing
session renegotiation, mbedtls_ssl_get_verify_result api returns value 0 in
above case
I am thinking in case of session renegotiation, a valid session will always
be available (it will not be NULL in the method below) and session
renegotiation failure information will be available with session_negotiate
pointer instead of session pointer in the below function.
uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl )
{
if( ssl->session != NULL )
return( ssl->session->verify_result );
if( ssl->session_negotiate != NULL )
return( ssl->session_negotiate->verify_result );
return( 0xFFFFFFFF );
}
Am I using the right API to get certificate verify_result?
should mbedtls_ssl_get_verify_result api checks give priority to
session_negotiate then session? I think when there is a failure, the result
will always be with session_negotiate, when success session_negotiate
becomes NULL and session_negotiate pointers will be assigned to session
pointers.
uint32_t mbedtls_ssl_get_verify_result( const mbedtls_ssl_context *ssl )
{
if( ssl->session_negotiate != NULL )
return( ssl->session_negotiate->verify_result );
if( ssl->session != NULL )
return( ssl->session->verify_result );
return( 0xFFFFFFFF );
}
Kind request to guide me
Thanks in advance
Regards
Hardik Dave
Yes, there's some kind of "memory magic" going on here:
The task got terminated due to "Load from invalid memory"
and I see:
|Instruction at 0x6310604d is trying to load data at 0x4, which is an
invalid memory area. You are probably dereferencing a NULL pointer.|
|and i got some trace back addresses that point to:|
*
mbedtls_aes_crypt_ecb
*
mbedtls_ctr_drbg_random_with_add
*
mbedtls_ssl_handshake_step
*
mbedtls_ssl_handshake
||
On 2021-06-08 11:43 a.m., Gilles Peskine via mbed-tls wrote:
> Hi Ron,
>
> This behavior can't be explained by the library code and the code you
> posted alone. There has to be something wrong elsewhere.
>
> Check that you aren't exceeding a limitation such as the stack size or
> the size of executable and data sections. If it can be an issue on your
> platform, check that load addresses are correct and sections don't
> overlap. Make sure there's no overlap with any device memory mapping either.
>
> Make sure that the whole binary is compiled with consistent settings.
> The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
> configuration, so make sure that there's a single copy of
> mbedtls/config.h and both Mbed TLS itself and your application were
> built against that copy. The layout of mbedtls_ssl_context can also be
> influenced by compiler settings on some platforms (e.g. structure
> packing options), so make sure those are consistent across your build.
>
> That's all I can think of for now. It may help to add a lot of printf
> debugging with %p on various addresses, and compare these addresses with
> what you know about memory mappings on that platform. Good luck!
>
Hi Ron,
This behavior can't be explained by the library code and the code you
posted alone. There has to be something wrong elsewhere.
Check that you aren't exceeding a limitation such as the stack size or
the size of executable and data sections. If it can be an issue on your
platform, check that load addresses are correct and sections don't
overlap. Make sure there's no overlap with any device memory mapping either.
Make sure that the whole binary is compiled with consistent settings.
The layout of mbedtls_ssl_context can be influenced by the Mbed TLS
configuration, so make sure that there's a single copy of
mbedtls/config.h and both Mbed TLS itself and your application were
built against that copy. The layout of mbedtls_ssl_context can also be
influenced by compiler settings on some platforms (e.g. structure
packing options), so make sure those are consistent across your build.
That's all I can think of for now. It may help to add a lot of printf
debugging with %p on various addresses, and compare these addresses with
what you know about memory mappings on that platform. Good luck!
--
Gilles Peskine
Mbed TLS developer
On 08/06/2021 19:16, Ron Eggler via mbed-tls wrote:
>
> On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote:
>> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
>>> Hi Ron,
>>>
>>> The code you've shown so far only consists of setup functions that
>>> populate fields in the configuration structure, then in the context
>>> structure. Communication has not started yet. mbedtls_ssl_set_bio in
>>> particular is a very simple setter function.
>>>
>>> Where does the code actually hang? Have some messages already been
>>> exchanged on the network at that point? Can you get a stack trace?
>>>
>>> Best regards,
>>>
>> Hi Gilles,
>>
>> Thank you for the response!
>>
>> I've inserted print statements after each of the setup functions and
>> can see that it never gets past mbedtls_ssl_set_bio. The messages
>> that have been exchanged, include the complete bring up and login of
>> the control channel, on the data channel, I call
>> mbedtls_x509_crt_init
>> mbedtls_pk_init
>> mbedtls_entropy_init
>> mbedtls_ctr_drbg_init
>> mbedtls_ssl_init
>> mbedtls_ssl_config_init
>> followed by the certificate and key file got parsing, seeding of the
>> RNG and that's where the previously mentioned procedure with
>> mbedtls_ssl_config_defaults() starts.
>> I unfortunately do not have a debugger available on that platform and
>> hence getting a stack trace won't be so straight forward. Do you have
>> any pointers as to what could be the issue potentially?
>>
>> Thank you,
>>
>> Ron
>
> Okay, I've made some further findings:
>
> I changed the mbedtls_ssl_set_bio funmction so that I inserted a print
> statement on entry and after every set line, like so:
>
> void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
> void *p_bio,
> mbedtls_ssl_send_t *f_send,
> mbedtls_ssl_recv_t *f_recv,
> mbedtls_ssl_recv_timeout_t *f_recv_timeout )
> {
> iprintf("mbedtls_ssl_set_bio::entry\n");
> ssl->p_bio = p_bio;
> iprintf("mbedtls_ssl_set_bio::p_bio set\n");
> ssl->f_send = f_send;
> iprintf("mbedtls_ssl_set_bio::f_send set\n");
> ssl->f_recv = f_recv;
> iprintf("mbedtls_ssl_set_bio::f_recv set\n");
> ssl->f_recv_timeout = f_recv_timeout;
> iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n");
> }
>
> and turns out, that I only see the very first print on
> "mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me
> to the believe that my *ssl is invalid which is odd as that variable
> is also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is
> initialized at the beginning of the function with mbedtls_ssl_init(
> &ssl_d );
>
>
On 2021-06-08 7:40 a.m., Ron Eggler via mbed-tls wrote:
> On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
>> Hi Ron,
>>
>> The code you've shown so far only consists of setup functions that
>> populate fields in the configuration structure, then in the context
>> structure. Communication has not started yet. mbedtls_ssl_set_bio in
>> particular is a very simple setter function.
>>
>> Where does the code actually hang? Have some messages already been
>> exchanged on the network at that point? Can you get a stack trace?
>>
>> Best regards,
>>
> Hi Gilles,
>
> Thank you for the response!
>
> I've inserted print statements after each of the setup functions and
> can see that it never gets past mbedtls_ssl_set_bio. The messages that
> have been exchanged, include the complete bring up and login of the
> control channel, on the data channel, I call
> mbedtls_x509_crt_init
> mbedtls_pk_init
> mbedtls_entropy_init
> mbedtls_ctr_drbg_init
> mbedtls_ssl_init
> mbedtls_ssl_config_init
> followed by the certificate and key file got parsing, seeding of the
> RNG and that's where the previously mentioned procedure with
> mbedtls_ssl_config_defaults() starts.
> I unfortunately do not have a debugger available on that platform and
> hence getting a stack trace won't be so straight forward. Do you have
> any pointers as to what could be the issue potentially?
>
> Thank you,
>
> Ron
Okay, I've made some further findings:
I changed the mbedtls_ssl_set_bio funmction so that I inserted a print
statement on entry and after every set line, like so:
void mbedtls_ssl_set_bio( mbedtls_ssl_context *ssl,
void *p_bio,
mbedtls_ssl_send_t *f_send,
mbedtls_ssl_recv_t *f_recv,
mbedtls_ssl_recv_timeout_t *f_recv_timeout )
{
iprintf("mbedtls_ssl_set_bio::entry\n");
ssl->p_bio = p_bio;
iprintf("mbedtls_ssl_set_bio::p_bio set\n");
ssl->f_send = f_send;
iprintf("mbedtls_ssl_set_bio::f_send set\n");
ssl->f_recv = f_recv;
iprintf("mbedtls_ssl_set_bio::f_recv set\n");
ssl->f_recv_timeout = f_recv_timeout;
iprintf("mbedtls_ssl_set_bio::f_recv_timeout set\n");
}
and turns out, that I only see the very first print on
"mbedtls_ssl_set_bio::entry\n" and nothing there after, which leads me
to the believe that my *ssl is invalid which is odd as that variable is
also used for ret = mbedtls_ssl_setup( &ssl_d, &conf_d ); and it is
initialized at the beginning of the function with mbedtls_ssl_init(
&ssl_d );
On 2021-06-08 12:28 a.m., Gilles Peskine via mbed-tls wrote:
> Hi Ron,
>
> The code you've shown so far only consists of setup functions that
> populate fields in the configuration structure, then in the context
> structure. Communication has not started yet. mbedtls_ssl_set_bio in
> particular is a very simple setter function.
>
> Where does the code actually hang? Have some messages already been
> exchanged on the network at that point? Can you get a stack trace?
>
> Best regards,
>
Hi Gilles,
Thank you for the response!
I've inserted print statements after each of the setup functions and can
see that it never gets past mbedtls_ssl_set_bio. The messages that have
been exchanged, include the complete bring up and login of the control
channel, on the data channel, I call
mbedtls_x509_crt_init
mbedtls_pk_init
mbedtls_entropy_init
mbedtls_ctr_drbg_init
mbedtls_ssl_init
mbedtls_ssl_config_init
followed by the certificate and key file got parsing, seeding of the RNG
and that's where the previously mentioned procedure with
mbedtls_ssl_config_defaults() starts.
I unfortunately do not have a debugger available on that platform and
hence getting a stack trace won't be so straight forward. Do you have
any pointers as to what could be the issue potentially?
Thank you,
Ron
Hi,
Can you please help Jun to find an answer to is question? (See below.)
/George
---------- Forwarded message ---------
发件人: Jun Nie <jun.nie(a)linaro.org>
Date: 2021年6月7日周一 下午2:31
Subject: How to map PSA method to openssl method
To: <mbed-tls(a)lists.trustedfirmware.org>
Hi,
I want to sign a data on PC with openssl, and verifiy it with PSA-RoT on board. Does anybody know how to map PSA method to openssl method?
Such as:
psa_sign_hash(key_handle,
PSA_ALG_DETERMINISTIC_ECDSA(PSA_ALG_SHA_256), hash, hash_len, sig, sizeof(sig), sig_len);
Regards,
Jun
Hi Ron,
The code you've shown so far only consists of setup functions that
populate fields in the configuration structure, then in the context
structure. Communication has not started yet. mbedtls_ssl_set_bio in
particular is a very simple setter function.
Where does the code actually hang? Have some messages already been
exchanged on the network at that point? Can you get a stack trace?
Best regards,
--
Gilles Peskine
Mbed TLS developer
On 08/06/2021 02:30, Ron Eggler via mbed-tls wrote:
>
> On 2021-06-07 5:00 p.m., Ron Eggler via mbed-tls wrote:
>> Hi,
>>
>>
>> i'm in the process of wrioting an FTPS client for a system running on
>> uCOS.
>>
>> I've been able to setup the control channel fine and working on
>> setting up the data channel for a simple list command execution.
>>
>> It seems like I seem able to setup everything fine but the call to
>> mbedtls_ssl_set_bio() hangs even though I set it to execute the
>> timeout function like:
>>
>> mbedtls_ssl_set_bio( &ssl_d,
>> &data_fd,
>> mbedtls_tls_send,
>> NULL,
>> mbedtls_tls_recv_timeout);
>>
>> Where the mbed_tls_recv_timeout looks like:
>>
>> https://pastebin.com/Jw3iLc0x
>>
>> The current connection uses ipv4, i.e. the select () branch is
>> active. I never see the timed out message. Any idea what may be going
>> on here?
>>
>> Thank you,
>>
>> Ron
>>
> A bit more detail: as for what comes before the mbedtls_ssl_set_bio()
> call:
>
> ret = mbedtls_ssl_config_defaults(&conf_d,
> MBEDTLS_SSL_IS_CLIENT,
> MBEDTLS_SSL_TRANSPORT_STREAM,
> MBEDTLS_SSL_PRESET_DEFAULT);
>
> mbedtls_ssl_conf_authmode( &conf_d, MBEDTLS_SSL_VERIFY_OPTIONAL);
> mbedtls_ssl_conf_ca_chain( &conf_d, &cacert_d, NULL );
> mbedtls_ssl_conf_rng(&conf_d, mbedtls_ctr_drbg_random, &ctr_drbg_d );
> mbedtls_ssl_conf_dbg(&conf_d, mydebug, stdout);
> ret = mbedtls_ssl_conf_own_cert( &conf_d, &clicert_d, &pkey_d);
>
> ret = mbedtls_ssl_setup( &ssl_d, &conf_d );
>
> mbedtls_ssl_set_bio( &ssl_d,
> &data_fd,
> mbedtls_tls_send,
> NULL,
> mbedtls_tls_recv_timeout);
>