lpac: OpenWRT libcurl & mbedtls not working with lpac

[Jason-Duffy]

Maintainer: @blocktrron Environment: ARM Cortex-A76, Raspberry Pi 5, OpenWRT Snapshot 5th Sept 2024

Description:

Problem

lpac relies on curl for HTTP operations, but the OpenWrt version of libcurl is compiled with mbedtls, which lacks certain features required for the necessary certificate reading and TLS handshake when provisioning eSIM profiles. Specifically, mbedtls on OpenWrt has difficulty reading the GSMA Root CA (which is signed with ecdsa-with-SHA256 ) and possibly does not support the necessary cryptography with the server (TLSv1.3 with TLS_AES_256_GCM_SHA384 ).

Due to these mbedtls limitations, curl on OpenWrt fails with errors like:

Error reading ca cert file gsmaroot.crt - mbedTLS: (-0x2080) X509 - Unavailable feature, e.g. RSA hashing/encryption combination

and:

SSL - Client received an extended server hello containing an unsupported extension during TLS handshakes

preventing successful eSIM profile provisioning.

Workaround

Recompiling libcurl with OpenSSL using OpenWrt's standard configuration, instead of mbedtls, resolves the cert reading and TLS handshake issues, allowing successful eSIM profile downloads and operations. However, given that mbedtls is the default OpenWrt library it would be good if possible to have it work with basic consumer esim operations with lpac.

[blocktrron]

As long as mbedtls does not support the required cryptographic functions, I suppose we can not do much about this.

However, the ca file should not be read, as curl is explicitly set to not validate the certificate authenticity (see https://github.com/estkme-group/lpac/blob/main/driver/http/curl.c#L94), how did you get this error?

I know that mbedtls does seem to have issues with some SM-DP+, however i did not have a look yet in which constellations. What i can say is that currently lpac works with the truphone SM-DP+ while it does not work with one from thales.

See:

https://www.ssllabs.com/ssltest/analyze.html?d=smdp.io https://www.ssllabs.com/ssltest/analyze.html?d=man-gto.prod.ondemandconnectivity.com

[lePereT]

I got the cert message when using curl directly and not lpac. I also had to compile my own image compiling libcurl against openssl, and then things worked.

The SM-DP+ I was having issues with using mbedtls was Lyca Mobile dp-plus-par07-01.oasis-smartsim.com

What is the issue with mbedtls? Is it just support for TLS_AES_256_GCM_SHA384? Or is there a deeper issue with mbedtls's featureset?

[brada4]

cabforum requirements added more certificate chain algos in august. https://cabforum.org/working-groups/server/baseline-requirements/documents/ You can check using qualys test that there is no other incompatibility past alt root certificate in a brand new format, site supports tls 1.2 and 1.3 with all possible ciphers.

[bam80]

What i can say is that currently lpac works with the truphone SM-DP+

How did you get it working? In my experiment (via a mbim wrapper, default libcurl with mbedTLS):

# lpac-mbim  profile download -s rsp.truphone.com -m QRF-SPEEDTEST -a 'LPA:1$rsp.truphone.com$QRF-SPEEDTEST'
INFO: Connect
INFO: Open channel with AID a0000005591010ffffffff8900000100
INFO: Received progress. Printing...
{'payload': {'code': 0,
             'data': 'rsp.truphone.com',
             'message': 'es10b_get_euicc_challenge_and_info'},
 'type': 'progress'}
INFO: Received progress. Printing...
{'payload': {'code': 0,
             'data': 'rsp.truphone.com',
             'message': 'es9p_initiate_authentication'},
 'type': 'progress'}
INFO: Received progress. Printing...
{'payload': {'code': 0,
             'data': 'rsp.truphone.com',
             'message': 'es10b_cancel_session'},
 'type': 'progress'}
INFO: Received progress. Printing...
{'payload': {'code': 0,
             'data': 'rsp.truphone.com',
             'message': 'es9p_cancel_session'},
 'type': 'progress'}
INFO: Received LPA data. Printing...
{'payload': {'code': -1,
             'data': 'HTTP transport failed',
             'message': 'es9p_initiate_authentication'},
 'type': 'lpa'}
INFO: Close channel 2
INFO: Disconnect
Exit code: 255

I tried test profiles from here: https://euicc-manual.osmocom.org/docs/rsp/known-test-profile/

[bam80]

Workaround

Recompiling libcurl with OpenSSL using OpenWrt's standard configuration, instead of mbedtls

Recompiling shouldn't be needed here, it's inappropriate requirement for users. Also, 2 variants of the library at once could just not fit into the flash. We definitely should find more appropriate solution.

I see no libcurl-openssl available, but there is libcurl-gnutls4, will it work?

[bam80]

What I have found master shouldn't have such a problem currently, needs testing: https://forum.openwrt.org/t/why-return-to-mbed-tls/162957/37?u=bam80