Hi guys,
I have a mbetls based server client application (DTLS) written in Apple Swift language, wrapping the mbedtls C api, running just fine for many years now on iOS, Android, and Linux. We have been compiling the code with Swift 5.0, 5.1, 5.2, 5.3, 5.4 in both release and debug mode.
Recently I just recompiled my code with Swift 5.5 in release mode, and my handshakes started failing on the Linux server with cryptic mbedtls_pk_sign() returned -17280 (-0x4380). When I take the same code and recompile in debug mode (-Onone) it works as expected. The same code compiled with Swift+C for iOS and macOS still works in both debug and release mode on both client/server.
If I understand the compilation process correctly, the Swift Package Manager that we use to wrap mbedtls simply uses CMakeLists.txt to compile mbedtls and pick up the right flags.
I am attaching excerpt from the log where the server part of the handshake fails (in release mode) and succeeds (in debug mode).
I am certain this is probably caused by my code and how I wrap C mbedtls sources in Swift, but I can not yet rule out a bug in Swift/C compiler part for Linux which from time to time does have bugs related to code optimization.
Could any good soul who understands the parts of the code below point me in the direction where to look and why would the mbedtls_pk_sign fail this way? What parts of the SSL context does it use? I will deep dive into the code to see whether this can be caused by memory corruption or anything else.
It’s on LTS mbedtls-2.16.11.
Could I run some tests to perhaps verify that mbedtls is compiled and working correctly?
thanks for any help,
Martin
— failing handshake —
Dec 7 15:54:53 ssl_srv.c:3296 => write server key exchange
Dec 7 15:54:53 ssl_srv.c:3074 ECDHE curve: secp521r1
Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(X)' (521 bits) is:
Dec 7 15:54:53 ssl_srv.c:3100 01 d0 5f 4a fa 12 f8 46 75 fb 3e 38 db ba 88 ff
Dec 7 15:54:53 ssl_srv.c:3100 73 72 79 78 21 dd 9f ac ac 02 db e7 7e 91 6e 5c
Dec 7 15:54:53 ssl_srv.c:3100 06 ed 77 19 42 f1 11 6a f5 75 04 20 d8 51 50 a5
Dec 7 15:54:53 ssl_srv.c:3100 8f 5a 3d 8c b3 c0 15 df cc d7 5b e5 eb 04 2e b6
Dec 7 15:54:53 ssl_srv.c:3100 2f e7
Dec 7 15:54:53 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (518 bits) is:
Dec 7 15:54:53 ssl_srv.c:3100 26 c1 52 f0 b6 20 4c aa 53 7c aa 27 12 5f 72 7f
Dec 7 15:54:53 ssl_srv.c:3100 11 ea a9 34 9a f5 ef 63 28 76 d8 52 4e 31 a3 13
Dec 7 15:54:53 ssl_srv.c:3100 52 a5 c9 52 5f 6b 41 b6 7e 47 0e 2a 68 c5 e5 80
Dec 7 15:54:53 ssl_srv.c:3100 14 27 ad aa 96 5b 89 41 55 5b d5 52 61 66 8c 06
Dec 7 15:54:53 ssl_srv.c:3100 4b
Dec 7 15:54:53 ssl_srv.c:3163 pick hash algorithm 8 for signing
Dec 7 15:54:53 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes)
Dec 7 15:54:53 ssl_srv.c:3201 0000: 55 c8 d2 5c 83 d8 6b e3 9f 9c b2 f4 e7 f7 4d 26 U..\..k.......M&
Dec 7 15:54:53 ssl_srv.c:3201 0010: b4 ce c9 df c2 ae 7a 60 cb e8 02 13 d5 6d d8 ec ......z`.....m..
Dec 7 15:54:53 ssl_srv.c:3201 0020: 48 72 77 9f e2 69 4e f5 b4 1d db 9a 75 2a 5e c7 Hrw..iN.....u*^.
Dec 7 15:54:53 ssl_srv.c:3201 0030: e1 1b 66 fc a6 ff 37 c6 6d 42 9b b3 cf 63 bb 0e ..f...7.mB...c..
Dec 7 15:54:53 ssl_srv.c:3274 mbedtls_pk_sign() returned -17280 (-0x4380)
Dec 7 15:54:53 ssl_tls.c:8219 <= handshake
— successful handshake —
Dec 7 16:13:52 ssl_srv.c:3296 => write server key exchange
Dec 7 16:13:52 ssl_srv.c:3074 ECDHE curve: secp521r1
Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(X)' (519 bits) is:
Dec 7 16:13:52 ssl_srv.c:3100 52 5f 4e 78 48 bd be 6a e4 98 21 30 ce 1c ba 08
Dec 7 16:13:52 ssl_srv.c:3100 b7 ae 88 d3 ff c9 c4 a5 8c 13 1e 73 5b 1f 08 60
Dec 7 16:13:52 ssl_srv.c:3100 7c 51 a7 ec 91 54 d7 52 f3 55 6a 34 92 cf 92 e8
Dec 7 16:13:52 ssl_srv.c:3100 c8 39 33 5e d3 46 3d 89 e7 6d 8f 41 d9 e0 67 e6
Dec 7 16:13:52 ssl_srv.c:3100 7c
Dec 7 16:13:52 ssl_srv.c:3100 value of 'ECDH: Q(Y)' (520 bits) is:
Dec 7 16:13:52 ssl_srv.c:3100 87 48 29 20 93 8e f8 9a a9 54 70 26 58 79 9d 67
Dec 7 16:13:52 ssl_srv.c:3100 8c ec 0f 06 ae 73 13 40 72 58 fe c1 6e 14 b4 48
Dec 7 16:13:52 ssl_srv.c:3100 55 a1 27 74 9d 63 36 aa db 80 29 f8 ab 9c 64 ba
Dec 7 16:13:52 ssl_srv.c:3100 f9 0a 19 af 9a 65 6f 02 96 c6 53 4d 49 4f b4 f5
Dec 7 16:13:52 ssl_srv.c:3100 46
Dec 7 16:13:52 ssl_srv.c:3163 pick hash algorithm 8 for signing
Dec 7 16:13:52 ssl_srv.c:3201 dumping 'parameters hash' (64 bytes)
Dec 7 16:13:52 ssl_srv.c:3201 0000: e1 65 f4 f0 a6 a3 67 7d 32 55 ed 2a 13 08 71 8a .e....g}2U.*..q.
Dec 7 16:13:52 ssl_srv.c:3201 0010: 7e 13 f6 30 85 ed c3 c9 10 e8 b2 43 75 bc 6c 24 ~..0.......Cu.l$
Dec 7 16:13:52 ssl_srv.c:3201 0020: 8f fb d8 90 cb 53 7f 13 53 13 1b f4 eb bd 38 5c .....S..S.....8\
Dec 7 16:13:52 ssl_srv.c:3201 0030: ec 46 c2 0c a9 93 5b 60 5e 5d 81 f2 b3 b0 b5 a8 .F....[`^]......
Dec 7 16:13:52 ssl_srv.c:3361 dumping 'my signature' (256 bytes)
Dec 7 16:13:52 ssl_srv.c:3361 0000: 7a a7 0f 17 79 33 36 b7 0c 17 84 5b cc ca 1c 0c z...y36....[....
Dec 7 16:13:52 ssl_srv.c:3361 0010: cb f5 56 80 ea 5d 7f cf ab 86 d5 f9 91 36 0e 68 ..V..].......6.h
Dec 7 16:13:52 ssl_srv.c:3361 0020: 76 c6 c0 4b 77 bf 28 e7 b8 c0 a7 de ea d8 a0 30 v..Kw.(........0
Dec 7 16:13:52 ssl_srv.c:3361 0030: 3a b3 4e 24 ea e0 c8 0b e7 ad ba 4d 35 30 c0 39 :.N$.......M50.9
Dec 7 16:13:52 ssl_srv.c:3361 0040: a8 ff f0 6d 8f 28 db fc 5e c3 fb 21 fe 76 dd 07 ...m.(..^..!.v..
Dec 7 16:13:52 ssl_srv.c:3361 0050: 1b 2c 58 fe 7b 0a f5 72 49 d9 d1 9a 10 af 29 21 .,X.{..rI.....)!
Dec 7 16:13:52 ssl_srv.c:3361 0060: 7a d9 01 a4 99 01 de 6e ae fd 76 ce b9 64 84 49 z......n..v..d.I
Dec 7 16:13:52 ssl_srv.c:3361 0070: 96 97 2d 3a 15 ed 5b de d5 99 9d 1b eb 4c 1a aa ..-:..[......L..
Dec 7 16:13:52 ssl_srv.c:3361 0080: a8 e6 36 29 bd 67 b0 50 91 6e b8 cb 0a 42 4a 79 ..6).g.P.n...BJy
Dec 7 16:13:52 ssl_srv.c:3361 0090: 4a 65 ae 95 d0 bc 5a e1 e7 75 2a f9 ba 51 1c 2c Je....Z..u*..Q.,
Dec 7 16:13:52 ssl_srv.c:3361 00a0: ff 67 e3 df eb a0 d7 6c d2 cf 71 d2 ea 24 7c 16 .g.....l..q..$|.
Dec 7 16:13:52 ssl_srv.c:3361 00b0: f8 5b 72 83 56 a9 48 e1 b6 cd d0 bd dd 20 23 d5 .[r.V.H...... #.
Dec 7 16:13:52 ssl_srv.c:3361 00c0: 80 c4 bd 6e 42 1c 61 b2 e4 41 01 ce c8 85 26 21 ...nB.a..A....&!
Dec 7 16:13:52 ssl_srv.c:3361 00d0: b4 0a 5e fe 50 0d 6f 45 a8 fe 15 18 87 e3 ae b3 ..^.P.oE........
Dec 7 16:13:52 ssl_srv.c:3361 00e0: ac 46 c5 c6 bb bc 70 1b 32 b7 15 c5 3d fb 09 1e .F....p.2...=...
Dec 7 16:13:52 ssl_srv.c:3361 00f0: 8f 69 f7 e7 a8 86 4d 0b 87 ea 4b fe 08 7e 00 0b .i....M...K..~..
Dec 7 16:13:52 ssl_tls.c:3289 => write handshake message
Dec 7 16:13:52 ssl_tls.c:2917 => ssl_flight_append
Dec 7 16:13:52 ssl_tls.c:2953 <= ssl_flight_append
Dec 7 16:13:52 ssl_tls.c:3425 <= write handshake message
Dec 7 16:13:52 ssl_srv.c:3380 <= write server key exchange
Hi,
Is it possible to run the benchmark of all cyphers natively on a ESP32
board? I have already run them on laptop but my goal is to run them on
esp32, using for example tool like espifd.
Hello
You are receiving this email because you are subscribed to one or more
mailing lists on lists.trustedfirmware.org.
The purpose of this email is to let you know that the software on the
server is being upgraded between Wednesday 29th December and Friday 31st
December. During that time, the server will be unavailable and any email
sent to a list on the server will be queued for later delivery.
After the upgrade has been completed, you will receive a follow-up email
from me to confirm that the upgrade has been completed and to provide you
with instructions on how to set up your account on the new server. With the
new software, you have one account regardless of how many mailing lists you
are subscribed to.
Regards
Philip Colmer
Director, Information Services
Linaro
Hello,
Is it possible to output a mbedtls_x509_crt as PEM or DER? I’ve been combing the API docs but don’t see how I can do this export. I see controls for exporting a newly-built cert, but not one that comes from, e.g., mbedtls_ssl_get_peer_cert().
Thank you!
Cheers,
-Felipe Gasper
https://gist.github.com/FGasper/43758d13e987518009d18ec8951ffcbb
^^ With 3.0.0 this prints:
seeded entropy
mbedtls connected
trust loaded ok
SNI set ok
handshake tried
handshake: X509 - Certificate verification failed, e.g. CRL, CA or signature check failed
… but if I switch to the development branch, it works.
Same trust chain, same code … but the production code fails while the dev one works …
Am I just “holding it wrong”?
Thank you in advance!
-FG
Hi All,
I am new here.
With a colleague, I am working on a product which previously used
PolarSSL but was later changed to MbedTLS which, in the ST ARM 32F417
implementation, is believed to be less buggy.
It is working ok as far as we have got, but we are finding that as
well as needing some 100k more FLASH, it needs nearly 50k of RAM,
which on the 32F417 (128k RAM) would normally be OK but due to other
required functionality it leaves us just 10k.
The architecture we are using for MbedTLS is a 48k (48k was found to
be the smallest that works) static buffer within which TLS runs its
own heap. I am aware that in the most generic case one has to have
enough for one 16k buffer (plus a bit) for HTTPS, but what concerns me
is that there appears to be no way to determine the worst case memory
usage, across various usage scenarios.
It would also be great to reduce this 48k to say 30k.
Some of the protocols we know we don't need (e.g. PPP) but within any
of them there is the question of which cipher suite needs supporting.
What is the minimum cipher suite required to be able to use MbedTLS as
an HTTPS client for use with typical current cloud-based file storage
or data logging APIs such as Dropbox, Google Drive, Loggly etc?
And what is the recommended minimum cipher suite required to implement
an HTTPS server that would be able to negotiate a session with most
current web-browsers?
The goal is to ideally reduce both RAM and code size requirements for
use in an embedded device that needs to work both as a general purpose
server and client, without requiring support for multiple concurrent
sessions.
The other thing is that even the ST port of MbedTLS doesn't appear to
make use of ST CPU hardware features such as AES256, DES, etc, which
the 32F417 has in hardware. This speeds things up hugely but much more
importantly in our case, saves a lot of RAM. For example AES256 can
use about 10k if done in software.
Thank you very much in advance for any input on what can be done.
Peter
Hello,
I am Marco Portoni and I am working on a thesis research for the University
of Study of Milan. It is focused on cryptographic libraries in the IoT
world, and my question is: is it possible to run the benchmark on a ESP32?
I have already runned the benchmark on 2 of my laptops to test and
collected the results, but my ultimate goal is to make the benchmark run
on the ESP. Is it possible to do it? Thanks for every help!
Marco
Hello,
I’m trying to build shared from git on macOS and having no luck. I’m doing:
> mkdir build; cd build
> cmake DUSE_SHARED_MBEDTLS_LIBRARY=On ..
…
> make
…
> ls -la library
total 2944
drwxr-xr-x 10 felipe staff 320 Dec 1 08:49 .
drwxr-xr-x 15 felipe staff 480 Dec 1 08:49 ..
drwxr-xr-x 8 felipe staff 256 Dec 1 08:49 CMakeFiles
-rw-r--r-- 1 felipe staff 92755 Dec 1 08:49 Makefile
-rw-r--r-- 1 felipe staff 2942 Dec 1 08:49 cmake_install.cmake
-rw-r--r-- 1 felipe staff 34055 Dec 1 08:49 error.c
-rw-r--r-- 1 felipe staff 916112 Dec 1 08:49 libmbedcrypto.a
-rw-r--r-- 1 felipe staff 315856 Dec 1 08:49 libmbedtls.a
-rw-r--r-- 1 felipe staff 104072 Dec 1 08:49 libmbedx509.a
-rw-r--r-- 1 felipe staff 26265 Dec 1 08:49 version_features.c
Am I just missing something? It seems like I’m following what the README says to do; I also did `export SHARED=1` just in case, but that made no difference.
Thank you in advance!
-FG
Hi Radhika,
We do not plan to extend support for Mbed TLS 2.16 beyond the three year support period.
We do plan to release a 2.x LTS (probably 2.28) alongside the final 2.16 release, so that we always have an LTS available.
Regards
Dave Rodgman
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Radhika Jandhyala via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Reply to: Radhika Jandhyala <radhikaj(a)microsoft.com>
Date: Monday, 22 November 2021 at 10:50
To: "mbed-tls(a)lists.trustedfirmware.org" <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] End of Life of LTS branch 2.16
Hi,
I am a maintainer for https://github.com/openenclave/openenclave. We include mbedtls 2.16 as a submodule in our project.
Reading the article below, it states that 2.16 support will last at least till Dec 2021. Will you continue to support 2.16 in 2022?
https://tls.mbed.org/tech-updates/blog/announcing-lts-branch-mbedtls-2.16
We are specifically interested in CVE fixes being backported to 2.16 and the timeframe where that will continue. Is there an updated timeline for this?
We do plan to upgrade to 3.0 in early 2022, but we anticipate that will take some effort due to breaking changes.
Thank you very much!
Radhika
Hi,
Mbed TLS 2.16 LTS is approaching the end of its support period – it was originally announced that it would be maintained for at least 3 years up until the end of 2021 – and currently there is no other LTS branch.
To ensure that there is no period of time without a supported LTS branch, we plan to release 2.28 LTS in the near future (which will have the usual 3 year support period). We will continue supporting 2.16 LTS until this is available. The expectation is that as 2.28 will be API-compatible with 2.16, users of 2.16 LTS will be able to upgrade to 2.28 very easily.
Progress towards 2.28 LTS can be followed here: https://github.com/orgs/ARMmbed/projects/18#column-15836286
Dave Rodgman
