Hello,
I
run a client that has been ported MbedTLS, but the client connect
server faild. I check the debug log, the end client state is 15. In the
client state 3, the client receive only one certificate from server,
and the log printing "Certificate verification flags 8". Here are part
of logs:
..\MbedTLS\library\ssl_tls.c:4232: dumping 'input record from network' (4467 bytes)
..\MbedTLS\library\ssl_tls.c:4232: 0000: 16 03 03 11 6e 0b 00 11 6a 00 11 67 00 05 c2 30 ....n...j..g...0
..\MbedTLS\library\ssl_tls.c:4232: 0010: -------- omit some network input data --------
..\MbedTLS\library\ssl_tls.c:4232: 0ff0: 38 a0 36 a0 34 86 32 68 74 74 70 3a 2f 2f 63 72 8.6.4.2http://cr
..\MbedTLS\library\ssl_tls.c:3624: handshake message: msglen = 4462, type = 11, hslen = 4462
..\MbedTLS\library\ssl_tls.c:4385: <= read record
..\MbedTLS\library\ssl_tls.c:5606: peer certificate #1:
..\MbedTLS\library\ssl_tls.c:5606: cert. version : 3
..\MbedTLS\library\ssl_tls.c:5606: serial number : F0:57:5F:65:80:A9:70:B4:F9:8E:42:91:AE:D0:70:27
..\MbedTLS\library\ssl_tls.c:5606:
issuer name : C=GB, ST=Greater Manchester, L=Salford, O=Sectigo
Limited, CN=Sectigo RSA Domain Validation Secure Server CA
..\MbedTLS\library\ssl_tls.c:5606: subject name : CN=*.xxxxxxxx.com
..\MbedTLS\library\ssl_tls.c:5606: issued on : 2020-06-01 00:00:00
..\MbedTLS\library\ssl_tls.c:5606: expires on : 2021-05-26 23:59:59
..\MbedTLS\library\ssl_tls.c:5606: signed using : RSA with SHA-256
..\MbedTLS\library\ssl_tls.c:5606: RSA key size : 2048 bits
..\MbedTLS\library\ssl_tls.c:5606: basic constraints : CA=false
..\MbedTLS\library\ssl_tls.c:5606: subject alt name : *.xxxxxxxx.com, xxxxxxxx.com
..\MbedTLS\library\ssl_tls.c:5606: key usage : Digital Signature, Key Encipherment
..\MbedTLS\library\ssl_tls.c:5606: ext key usage : TLS Web Server Authentication, TLS Web Client Authentication
..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.N' (2048 bits) is:
..\MbedTLS\library\ssl_tls.c:5606: af b7 73 1a f9 8a 2d 5e a2 e8 0f fd 89 5d 60 1d
..\MbedTLS\library\ssl_tls.c:5606: -------- omit some bits --------
..\MbedTLS\library\ssl_tls.c:5606: e6 8e f8 3e ed ec 8e dd ec 46 48 85 9a b4 c8 71
..\MbedTLS\library\ssl_tls.c:5606: value of 'crt->rsa.E' (17 bits) is:
..\MbedTLS\library\ssl_tls.c:5606: 01 00 01
..\MbedTLS\library\ssl_tls.c:5757: x509_verify_cert() returned -9984 (-0x2700)
..\MbedTLS\library\ssl_tls.c:5851: ! Certificate verification flags 8
..\MbedTLS\library\ssl_tls.c:5863: <= parse certificate
At
the client side, I download certificate of server, and get CA and root
CA base on this certificate. Loading any one of these certificates into
the client can't connect server.
I
did a test with another server. The different of the handshark is that
the server issued two certificates, one is server's cert and another is
CA cert. Loading CA or root CA into the client both can connect server
successfully.
problems:
1. Must the server send CA certificate in handshake phase?
2. The client holds CA certificate, dose MbedTLS client support downloading CA base on server's certificate?
3. In the source code, the certificate chain only contains the
certificate issued by the server during handshake, not the CA
certificate downloaded by the client according to the server
certificate?
Thank you very much for the answers.
Best regards,
berry chen
Hi Raoul,
Do I understand correctly that the problem with Mbed TLS as it is now is
that you need MBEDTLS_HAVE_ASM enabled for AESNI and disabled for
bignum? Would you want even more granularity?
In principle, we could create a new compile-time option MBEDTLS_MPI_ASM,
defaulting to what it does now (enabled if MBEDTLS_HAVE_ASM if the
platform is one of the known ones) but overridable in either direction.
However I don't like it much because we're trying to cut down on
compilation options to reduce the maintenance burden: each compilation
option adds complexity which makes it harder to understand all
interactions between different parts of the library, and adds some
testing burden. Symmetric and asymmetric crypto are mostly decoupled, so
this one wouldn't be too bad, but it all adds up.
In the long term, I expect that the different cryptographic algorithms
will become more decoupled, with a possibility to treat each one as a
black box that could be implemented by a hardware driver, and with a
uniform mechanism to select drivers (or maybe they should be called
engines). The evolution of the crypto part of the library to PSA is
going in this direction. But we aren't there yet.
Sorry that I don't have a more satisfying answer here.
--
Gilles Peskine
Mbed TLS developer
On 31/03/2021 09:13, Raoul Strackx via mbed-tls wrote:
> Hi all,
>
> We have a product that requires very strong security measures. When
> compiling the mbedtls library, we face the following issue: Compiling C
> code with LVI-mitigations is often much faster than relying on automatic
> LVI mitigations on assembly code. The MPI functions are a good example
> where we wish to rely on C source code. For other functions, we need to
> rely on assembly code in order to mitigate other vulnerabilities (e.g.,
> we require AESNI assembly instructions over C implementations of AES).
> Currently there isn't an option to choose between C/assembly per function.
>
> What would be an acceptable solution for this?
>
> greetings,
>
> Raoul
>
>
>
Hello,
In a nutshell:
1. Must Mbed TLS support Python 3.4 to configure and test, or can 3.6 be
enough?
2. Must the supplied CMake scripts support 2.8.12.2, or can 3.5.2 be enough?
This thread is about minimum tool versions to configure, build and test
Mbed TLS (excluding TLS interoperability testing and some maintainer
scripts) on Linux and similar (Unix-like) platforms. (This is not about
the set of platforms where Mbed TLS will _run_, which is as close to
“anything with CHAR_BIT==8 and sizeof(size_t) >= 4” as we can make it.)
Our general guideline is that Mbed TLS should build out of the box on
supported versions of major desktop and server operating systems. In
practice, this has tended to mean supporting tool versions from
RHEL/CentOS, SLES and Ubuntu LTS releases (but not necessarily extended
security maintenance releases).
Last year
(https://lists.trustedfirmware.org/pipermail/mbed-tls/2020-April/thread.html)
we concluded that we should support the following minimum versions,
which will remain supported in the Mbed TLS 2.16 long-time support (LTS)
branch:
clang 3.8
cmake 2.8.12.2
gcc 4.4
make 3.81
python 3.4 (in 2.16: only to build the unit tests, not to configure)
Since then, RHEL 6 and Ubuntu 16.04 have reached their end of life, the
CentOS world has changed considerably. Looking at maintained platforms
after April 2021
(https://github.com/ARMmbed/mbedtls/issues/2896#issuecomment-603471273),
our current goal for the upcoming Mbed TLS 2.x LTS (last release before
3.0) is:
clang 6.0
cmake 2.8.12.2 (or 3.5.2? or 3.10.2?)
gcc 4.8
make 3.82
python 3.6 (or 3.4.10?)
Regarding Python: is there any demand for supporting Python versions
older than 3.6? Python 3 is required to fine-tune the library
configuration (it is not needed if you use the default config.h or a
handwritten one) and build the unit tests.
Regarding CMake: it is increasingly problematic for us to support CMake
2.8.12, which is only required for RHEL 7: other distributions under
consideration have at least CMake 3.5. There is an ongoing effort to
improve our CMake scripts to make it easier to integrate Mbed TLS into a
larger project, but it is difficult to preserve backward compatibility
with 2.8.12. Would it be acceptable to require CMake >= 3.5? CMake >=
3.10.2?
If you have any constraints that are not captured here or if you have an
opinion regarding Python and CMake versions, please let us know quickly.
--
Gilles Peskine
Mbed TLS developer
Hi all,
We have a product that requires very strong security measures. When
compiling the mbedtls library, we face the following issue: Compiling C
code with LVI-mitigations is often much faster than relying on automatic
LVI mitigations on assembly code. The MPI functions are a good example
where we wish to rely on C source code. For other functions, we need to
rely on assembly code in order to mitigate other vulnerabilities (e.g.,
we require AESNI assembly instructions over C implementations of AES).
Currently there isn't an option to choose between C/assembly per function.
What would be an acceptable solution for this?
greetings,
Raoul
Also, if you're looking for a hardware platform with PSA Crypto drivers,
Silicon Labs has one available. They've been participating in Mbed TLS
development recently and a large part of the driver support code added
in the past few months comes from them. You can see the documentation of
their development kit at https://docs.silabs.com/mbed-tls/latest/ . (If
you want to know about getting sample hardware and driver code … I'm not
the right person to ask.)
--
Gilles Peskine
On 24/02/2021 22:26, Gilles Peskine via mbed-tls wrote:
> Hi Frank,
>
> I'm not sure what you're looking for. Do you mean open source projects
> like Curl and Hiawatha that can use Mbed TLS as a cryptography provider?
> Those are generally using the classic API, and so can't make generic use
> of secure elements. I am aware of private projects using the limited
> features available today (for example, TLS servers can use async private
> key operations to put the key in an HSM — see
> https://tls.mbed.org/kb/how-to/ssl_async).
>
> I've used SoftHSM in the past as a way to test portable PKCS#11 client
> code without hardware. It did the job well. I can't speak for the
> quality of its cryptography since I was only using it for testing.
>
> If you're looking for a generic interface between applications and
> secure elements, then I would recommend PSA crypto over PKCS#11. We did
> try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of
> course PKCS#11 is old and venerable, whereas PSA is new and the support
> for hardware secure elements is still a work in progress.
>
Hi Frank,
I'm not sure what you're looking for. Do you mean open source projects
like Curl and Hiawatha that can use Mbed TLS as a cryptography provider?
Those are generally using the classic API, and so can't make generic use
of secure elements. I am aware of private projects using the limited
features available today (for example, TLS servers can use async private
key operations to put the key in an HSM — see
https://tls.mbed.org/kb/how-to/ssl_async).
I've used SoftHSM in the past as a way to test portable PKCS#11 client
code without hardware. It did the job well. I can't speak for the
quality of its cryptography since I was only using it for testing.
If you're looking for a generic interface between applications and
secure elements, then I would recommend PSA crypto over PKCS#11. We did
try to make PSA Crypto a better PKCS#11. Obviously I'm biased :) But of
course PKCS#11 is old and venerable, whereas PSA is new and the support
for hardware secure elements is still a work in progress.
--
Gilles Peskine
Mbed TLS developer and PSA Crypto architect
On 21/02/2021 17:11, Frank Bergmann via mbed-tls wrote:
> Hi Gilles,
>
> thank you for your detailled answer.
> Honestly I was in fear that your answer would look like this. ;-)
>
> Do you maybe know of any plans of any software project to use mbed TLS
> together with a secure element?
>
> I asked SoftHSM because it looks much promising for our goals but they
> answered that they don't have any plans to use different ssl libs.
>
>
> cheers,
> Frank
>
>
> On 08.02.21 23:07, Gilles Peskine via mbed-tls wrote:
>> Hi Frank,
>>
>> Support for HSM keys in Mbed TLS is a work in progress. The way it will
>> work eventually is by plugging an HSM driver under the PSA crypto API,
>> which supports both transparent and opaque keys.
>>
>> The TLS code can already use the PSA crypto API for some things,
>> including client signature. Enable MBEDTLS_USE_PSA_CRYPTO, call
>> mbedtls_pk_setup_opaque() to create a PK object for the key, and declare
>> the key to the TLS code with mbedtls_ssl_conf_own_cert() as usual.
>>
>> To create the key, you will need to write a PKCS#11 secure element
>> driver. ("Secure element" = "HSM" for this purpose.) I think it would
>> make sense to have one in Mbed TLS, but I don't know when we might get
>> around to writing one.
>>
>> There are two secure element driver interfaces in Mbed TLS right now:
>> MBEDTLS_PSA_CRYPTO_SE_C (dynamic secure element interface) and
>> MBEDTLS_PSA_CRYPTO_DRIVERS (unified driver interface). Both are still
>> experimental: we can't guarantee API stability at this stage.
>> MBEDTLS_PSA_CRYPTO_SE_C was the first proposal, and its development is
>> currently frozen and may be abandonned, so I don't recommend investing
>> any effort in it at the moment, but if you need something fast (e.g. for
>> a demo/proof-of-concept), it's your best bet. MBEDTLS_PSA_CRYPTO_DRIVERS
>> is the way of the future, but it's an active work in progress.
>>
>> If you're creating the key from your application, just call
>> psa_generate_key. If the key was provisioned externally, it's
>> unfortunately not so easy. With MBEDTLS_PSA_CRYPTO_SE_C, you can
>> register a key that's already present in the secure element with
>> mbedtls_psa_register_se_key(). The corresponding facility in the
>> MBEDTLS_PSA_CRYPTO_DRIVERS interface is a "get_builtin_key" entry point,
>> but this is not implemented yet. (There's a prototype at
>> https://github.com/ARMmbed/mbedtls/pull/3822 but nobody is working on
>> it. The specification is in docs/proposed/psa-driver-interface.md.)
>>
>> There's an example application with a MBEDTLS_PSA_CRYPTO_SE_C driver at
>> https://github.com/ARMmbed/mbed-os-example-atecc608a . We don't have
>> example code for MBEDTLS_PSA_CRYPTO_DRIVERS yet, or good documentation,
>> or an easy-to-use build system — those are still a few months in the future.
>>
>> If you write a driver in the next few months, I recommend that you stay
>> in touch with the Mbed TLS development team and follow the development
>> branch of Mbed TLS closely, since it's a very active area of development
>> at the moment.
>>
Hi Gábor,
Yes, it is ready for review, I have added the corresponding labels. Now there is nothing else to do just to wait for the reviews.
Best regards,
Janos
From: mbed-tls <mbed-tls-bounces(a)lists.trustedfirmware.org> on behalf of Gábor Tóth via mbed-tls <mbed-tls(a)lists.trustedfirmware.org>
Date: Tuesday, 23 February 2021 at 06:29
To: mbed-tls(a)lists.trustedfirmware.org <mbed-tls(a)lists.trustedfirmware.org>
Subject: [mbed-tls] PR-4161-merge TLS Testing — Failures: ABI-API-checking
Hello Guys!
AFter a week of debugging yesterday I was able to solve the issues on my PR, but the ABI-API failure is still on. I was told that based on my changes it is OK, I should not worry.
Does this mean that my PR is ready for review or it should have disappeared by now? In the second case could someone provide me the jenkins reports and some idea where should I start searching?
This is my PR:
https://github.com/ARMmbed/mbedtls/pull/4161
Thank you in advance!
BR,
Gábor
Hello Guys!
AFter a week of debugging yesterday I was able to solve the issues on my
PR, but the ABI-API failure is still on. I was told that based on my
changes it is OK, I should not worry.
Does this mean that my PR is ready for review or it should have disappeared
by now? In the second case could someone provide me the jenkins reports and
some idea where should I start searching?
This is my PR:
https://github.com/ARMmbed/mbedtls/pull/4161
Thank you in advance!
BR,
Gábor
