Fix SSL issues

[mikee47]

This PR aims to address some issues encountered whilst trying to use SSL for a basic HttpClient download session.

Fix malloc_count link error 'undefined reference to __wrap_strdup`

Implementation also needs to call mc_malloc, not malloc.

AxCertificate destructor accesses ssl after it's been destroyed

Picked up by valgrind.

Provide time implementations in RTC.cpp, add test

Library code requires libc implementations for gettimeofday and time_t.
On Esp8266 typically get please start sntp first ! message.
This should be synced with SystemClock so removed the time replacement code from AXTLS and use that.

Test added to HostTests to ensure SystemClock and time() are synced. Checked on esp8266, rp2040, esp32s2, host.

Replace automatic SSL certificate generation with generate-cert build target

These don't need to be auto-generated as they're not always required.
There are also multiple ways to get this information into an application.
Several samples don't make use of these files, so removed.

NOTE: The make_certs.sh script no longer appears to work, at least with openssl 3.2.1 (Jan 2024).
The headers are generated but Axtls fails to load the certificate with -269 (SSL_ERROR_INVALID_KEY).

Put generated SSL certificate information into PROGMEM

Bit wasteful of RAM.

Enforce consistent 'verifyLater' behaviour with Bearssl

When attempting to fetch an https resource (using HttpClient) without setting request onSslInit we get this behaviour:

• Axtls: Fails with X509_VFY_ERROR_NO_TRUSTED_CERT
• Bearssl: No problem, goes right ahead.

This behaviour with Bearssl is not desirable as it could inadvertently compromise security.
Add a check on verifyLater and fail with X509_NOT_TRUSTED as appropriate.

Notes

• Add setSslInitHandler method to HttpClient? NO ! Use request->onSslInit
• Does this work with lwip2 on esp8266? Doesn't appear to make things worse, but lwip2 looks to be kinda broken. Needs major update.
• Certificate generation throws errors with openssl 3, this needs addressing separately as it's only really appropriate for basic testing anyway.

[mikee47]

I don't have good answers for the SSL certificate generation, help appreciated!

NB. Does this deserve an issue?

[slaff]

Add setSslInitHandler method to HttpClient
Currently no way to provide this for a HttpClient.

The HttpClient acts like a browser that can make multiple requests. You set the SSL settings on the request. See https://github.com/SmingHub/Sming/blob/develop/samples/HttpClient/app/application.cpp#L109 . Or you wanted to add a method which checks certificates against a certificate store?

[mikee47]

You set the SSL settings on the request.

Thank you! Knew I'd missed something.

[mikee47]

Add setSslInitHandler method to HttpClient
Currently no way to provide this for a HttpClient.

The HttpClient acts like a browser that can make multiple requests. You set the SSL settings on the request. See https://github.com/SmingHub/Sming/blob/develop/samples/HttpClient/app/application.cpp#L109 . Or you wanted to add a method which checks certificates against a certificate store?

No nothing so complicated as this. The thing that tripped me up was that with ENABLE_SSL=Bearssl I can fetch https resources with no code modifications, but for ENABLE_SSL=Axtls I need onSslInit. This is inconsistent and the behaviour should be similar regardless of which SSL stack is being used. I'm not sure ATM which is better/more secure/simpler though: do we enforce use of onSslInit or remove the restriction for Axtls?

[slaff]

.. or remove the restriction for Axtls?

If one wants a fast SSL validation of a SSL certificate then fingerprint validation can be one of the few options without compromising security too much. A proper validation will require a correct time to be set on the device before validation. This will make also Axtls work as expected but the overall process will be slower.

[mikee47]

.. or remove the restriction for Axtls?

If one wants a fast SSL validation of a SSL certificate then fingerprint validation can be one of the few options without compromising security too much. A proper validation will require a correct time to be set on the device before validation. This will make also Axtls work as expected but the overall process will be slower.

To clarify, when attempting to fetch an https resource without setting onSslInit results in different behaviours:

• Axtls: Fails with X509_VFY_ERROR_NO_TRUSTED_CERT
• Bearssl: No problem, goes right ahead.

So from what you are saying this behaviour with Bearssl is not desirable as it could compromise security.

I'll see if there's a way to get Bearssl to return X509_NOT_TRUSTED error in this situation.

[slaff]

@mikee47 can you look at the Codacy issue: https://app.codacy.com/gh/SmingHub/Sming/pull-requests/2788/issues#issue-7a3d400681ced80723f87a41cc604ff2