HTTPS without T-FM and PSA

RE: HTTPS without T-FM and PSA

Daniel Figueira — Wed, 10 Jul 2024 11:09:37 GMT

After a lot of trial and error I finally got HTTPS working:

Over WiFi: using the nRF7002DK (both with and without TFM - meaning the secure and the non-secure builds).
Over LTE: using the nRF9161DK.
Over Ethernet: using the nRF9161DK with an ethernet port extension.

Apart from these I also got it working on our custom WiFi and LTE/Ethernet boards, which are based on the 2 development kits just mentioned.

To wrap things up I'll post a description of what I had to do:

1) In the first place I had to make sure all the certificates I imported are NULL terminated, otherwise I would get an error when importing them (already mentioned in a previous post).

2) In the second place I had to make sure the code which imports the certificates (which is different between LTE and Wifi/Ethernet) was correct and was being called before the network connection was established.

#if defined(USE_LTE)
    bool present_in_modem = false;

    // Check if a certificate with the same tag is already present in the modem
    // (since the certificates added to the modem are persistent).
    if (!present_in_modem) {
        ret = modem_key_mgmt_exists(tag, MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, &present_in_modem);
        if (ret != 0) {
            LOG_ERR("Failed to check if TLS certificate with tag %d is already present "
                    "on the modem (err: %d)",
                tag, ret);
            return ret;
        }
    }

    // Delete the old certificate (if different from the new)
    if (present_in_modem) {
        ret = modem_key_mgmt_cmp(tag, MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, certificate, certificate_size);
        if (ret < 0) {
            LOG_ERR("Failed to compare new TLS certificate with the one already"
                    "present on the modem (err: %d)",
                ret);
            return ret;
        }
        // If the certificates do not match
        if (ret == 1) {
            ret = modem_key_mgmt_delete(tag, MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN);
            if (ret < 0) {
                LOG_ERR("Failed to delete existing TLS certificate (err: %d)", ret);
                return ret;
            }
            present_in_modem = false;
        }
    }

    // Add the new certificate (if not already present)
    if (!present_in_modem) {
        ret = modem_key_mgmt_write(tag, MODEM_KEY_MGMT_CRED_TYPE_CA_CHAIN, certificate, certificate_size);
        if (ret < 0) {
            LOG_ERR("Failed to add TLS certificate (err: %d)", ret);
            return ret;
        }
    }
#endif   // USE_LTE

#if defined(USE_ETHERNET) || defined(USE_WIFI)
    // Try to add the new certificate
    ret = tls_credential_add(tag, TLS_CREDENTIAL_CA_CERTIFICATE, certificate, certificate_size);
    if (ret < 0 && ret != -EEXIST) {
        LOG_ERR("Failed to add TLS certificate (err: %d)", ret);
        return ret;
    }

    // If a certificate with the same tag already was present delete it and try again
    // (since we don't have a way to verify if the certificate is the same)
    if (ret == -EEXIST) {
        ret = tls_credential_delete(tag, TLS_CREDENTIAL_CA_CERTIFICATE);
        if (ret < 0) {
            LOG_ERR("Failed to delete existing TLS certificate (err: %d)", ret);
            return ret;
        }
        ret = tls_credential_add(tag, TLS_CREDENTIAL_CA_CERTIFICATE, certificate, certificate_size);
        if (ret < 0) {
            LOG_ERR("Failed to add TLS certificate (err: %d)", ret);
            return ret;
        }
    }
#endif   // USE_ETHERNET || USE_WIFI

I took me a while to understand that the certificates stored in the modem are persistent and stay on the modem even when I flash my board (for the LTE version at least...). This, grouped with some nasty bug I introduced when comparing the certificates, gave me a lot of headaches and resulted in very weird behaviors when trying to import different sets of certificates at the same time. Also good to know is that the value 0 is not a valid TAG and will result in a very hard-to-relate error (like all certificate and socket connection errors...).

The tags used will then need to be added using setsockopt() when creating a TLS socket:

    // Open a new HTTPS socket
    connection.socket = socket(AF_INET, SOCK_STREAM, IPPROTO_TLS_1_2);
    if (connection.socket < 0) {
        LOG_ERR("Unable to create local HTTPS socket (err: %d, %s)", errno, strerror(errno));
        return -errno;
    }

    // Set TLS credentials to be used
    ret = setsockopt(connection.socket, SOL_TLS, TLS_SEC_TAG_LIST, certificate_tags, certificate_count * sizeof(sec_tag_t));
    if (ret < 0) {
        LOG_ERR("Failed to set TLS certificate list (err: %d, %s)", errno, strerror(errno));
        disconnect();
        return -errno;
    }

One would expect connect() to now work, however at this point you will most likely run into one or more somewhat obscure error codes returned by the connect() method - leading us to point 3...

3) Make sure you're using the right zephyr configurations, based on the network type, zephyr build (secure vs. non-secure) and the type of certificates used.

For me this was the hardest step, since I had to rely mostly on trial and error to come up with the minimal set of configs I seem to need:

config USE_HTTPS
    bool "Enable HTTPS requests"
    default n
    select USE_HTTP
    # LTE dependencies
    select MBEDTLS_CCM_C if USE_LTE
    select MBEDTLS_ECP_C if USE_LTE
    select MBEDTLS_TLS_LIBRARY if USE_LTE
    # WiFi dependencies
    select MBEDTLS_RSA_C if USE_WIFI
    select PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY if USE_WIFI && !BUILD_WITH_TFM
    select PSA_WANT_RSA_KEY_SIZE_4096 if USE_WIFI && !BUILD_WITH_TFM
    # Ethernet dependencies
    select MBEDTLS_RSA_C if USE_ETHERNET
    select PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY if USE_ETHERNET
    select PSA_WANT_RSA_KEY_SIZE_4096 if USE_ETHERNET

    help
        Enable the use of HTTPS requests

# Configure the TLS heap size
# Note: needs to be adjusted depending on the number of certificates being 
# used at the same time. Seems to cause problems if smaller than 60000.
configdefault MBEDTLS_HEAP_SIZE
    default 81920 if USE_WIFI && !BUILD_WITH_TFM
    default 81920 if USE_ETHERNET

# Configure the MPI component buffers sizes (used for public key operations)
# Note: needs to be adjusted depending on the max RSA key size supported
configdefault MBEDTLS_MPI_MAX_SIZE
    default 512 if PSA_WANT_RSA_KEY_SIZE_4096
    default 256 if PSA_WANT_RSA_KEY_SIZE_2048

# Enable TLS level error logs for HTTPS operations
# TLS error code list: https://gist.github.com/erikcorry/b25bdcacf3e0086f8a2afb688420678e
config ENABLE_HTTPS_DEBUG_MODE
    bool "Enable TLS error logs"
    default n
    depends on USE_HTTPS
    select MBEDTLS_DEBUG
    select MBEDTLS_DEBUG_C
    select MBEDTLS_SSL_DEBUG_ALL
    help
        Enable TLS error logs during HTTPS operations

# Increase the MBEDTLS_DEBUG_LEVEL further if more details are needed
configdefault MBEDTLS_DEBUG_LEVEL
    default 1 if ENABLE_HTTPS_DEBUG_MODE

(note that these only contain the configs I had to add on top of the configs already present for normal HTTP...)

For these I had to take in consideration the types of certificates I was trying to use (namely the algorithm and the key size) and adjust my settings accordingly.

For google.com for example, I needed to enable the RSA algorithm and add support for 2048 byte sized keys (this is a picture of the Firefox web browser which I used to download the certificates I needed)...

At this point it really helped to enable the MBEDTLS error logs as suggested by Stefan Schmidt.

Then I needed to make sure I had enough space for the heap and the buffers that are used by the TLS libs - since I'm not using only a specific certificate but a list of certificates that might vary in number/type.

I was then able to successfully connect to different servers using the certificates I had, however there was still one step left I had to do...

4) Understanding how the Zephyr http_client layer works and the specifics of the servers I'm connecting to (which applies to both HTTP and HTTPS requests).

At this point I was able to successfully send HTTP requests over TLS to the servers, however this didn't meant that the servers would accept the requests I was sending, or maybe some servers did and some others did not... So, after doing some debugging and comparing the requests being sent using Zephyr's http_client versus the raw HTTP requests sent by the HTTPS sample I ended up with some not-so-obvious rules when it comes to building HTTP requests using Zephyr's http_client, which seem to make the requests I'm sending compatible across different servers:

The http_request 'url' field should not be left as NULL. When sending a request to the root path of the server the url needs to be set to '\' instead.
The http_request 'port' field is better left unset. Passing a value to it will cause the port to be appended to the "Host:" header of the request that is automatically generated by the http_client - which will cause some servers to reject your requests.
The hostname should either be added to the http_request 'host' field or present in the 'Host:' header set through the http_request 'headers' field, but not both - since it will cause the "Host:" header to be duplicated which might cause problems on the server side.
The "Content-Length:" header should not be used since it is already automatically generated based on the http_request 'body_len' field (even if left unset/zeroed).
All headers manually added to the http_request 'headers' field should to be \r\n terminated - otherwise the request will be malformed.

I was then finally able to send my HTTPS request to multiple servers, over different network types, with and without T-FM.

Hopefully this will be of use for those who face similar problems in the future...

I'm open to any further comments you might have, otherwise feel free to close this topic.

Best regards,
Daniel

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Wed, 26 Jun 2024 06:57:05 GMT

Since last time we talked here, a collegua of me made changes to a sample that may be what you need:

RE: Example code for HTTPS client using WiFi nRF7002 + nRF5340

See the last comment in this ticket.
Is this what you need?

RE: HTTPS without T-FM and PSA

Daniel Figueira — Tue, 25 Jun 2024 12:25:46 GMT

Sorry for not providing any updates in a long time, but I've been pretty busy...

Honestly, apart from project configuration you provided on how to run the HTTPS sample without TF-M, the rest of the answers I got weren't really helpful, so we gave up on trying to HTTPS requests with no TF-M on a nRF7002DK board around a month ago...

Instead we decided to move onto a nRF9160 board and send the HTTPS requests over LTE - which as been working fine for now.

Eventually we are going to want to have the same behavior over WiFi and maybe then I'll have to try to tackle this issue once again... but for now I'm not sure when that will happen.

RE: HTTPS without T-FM and PSA

Stefan Schmidt — Thu, 13 Jun 2024 06:38:10 GMT

Hi Daniel,

what I found very helpful in debugging TLS were these debug settings:
CONFIG_MBEDTLS_DEBUG=y
CONFIG_MBEDTLS_DEBUG_C=y
CONFIG_MBEDTLS_DEBUG_LEVEL=4
CONFIG_MBEDTLS_LOG_LEVEL_DBG=y
CONFIG_MBEDTLS_SSL_DEBUG_ALL=y
CONFIG_LOG_BUFFER_SIZE=20000

(provided by Hakon here: https://devzone.nordicsemi.com/f/nordic-q-a/110151/configuration-for-native-tls-no-offload-to-modem)

and this page with an overview of MBED TLS errors:

https://gist.github.com/erikcorry/b25bdcacf3e0086f8a2afb688420678e

Best regards

Stefan

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Wed, 12 Jun 2024 13:55:51 GMT

https://github.com/nrfconnect/sdk-nrf/tree/v2.6.1/samples/net/aws_iot/certs

https://github.com/nrfconnect/sdk-nrf/blob/eef645c4a31201df353fdff5447262d7675fa1c1/samples/net/aws_iot/CMakeLists.txt#L21

RE: HTTPS without T-FM and PSA

Stefan Schmidt — Wed, 12 Jun 2024 05:39:22 GMT

Hi Daniel,

how do you use the certificate in your firmware?

I usually download the certificates, modify them like described here ( https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.5.0/nrf/libraries/modem/modem_key_mgmt.html#certificates) and include them in an C array:

const uint8_t g_ca_certificate[] = {

#include "../cloud-certs/AmazonRootCA1.pem"

};

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Thu, 25 Apr 2024 13:10:37 GMT

What you need is to read up on Certificate Authorities (CAs).

I will try to sum it up: Webpages are signed with a cert. You can use a public key to verify the signature. But you must trust the signer, so the signer is always a CA.

The key you put on the device to trust the page is a CA public key.

All webpages do not have the same CA, so if you connect to two pages with different CAs, you will need different CA keys. Web browsers have a lot of CA keys in them for this reason.

For the nRF9160, you usually only need to connect to a handful of web pages for a product, so it is in most cases enough one CA key.

Disclaimer: I am probably not 100% correct, so I suggest you read on this from some more knowledgable source on the web

Did this make sense?

RE: HTTPS without T-FM and PSA

Daniel Figueira — Thu, 25 Apr 2024 12:33:37 GMT

Hi once again.

Maybe just to clarify, my end goal is to be able to perform HTTPS requests without the use of TF-M (previously I was unaware I could use PSA without TF-M) - ultimately we basically want to send data through HTTPS to an AWS server.

With the HTTPS_client sample configs you provided I guess it is now proven that having HTTPS without TF-M can be done (which was not covered by the Wifi Fundamental tutorials)...

However, after following your advice on how to download the certificates I needed through my web browser, I seem unable to use the HTTPS_client sample to connect to any server I tried except for "example.com" and "echo.thingy.rocks" (which I managed to connect to after updating the version of the certificate I previously had).

For any other well-known addresses out there, like 'google.com' for instance, I always get a ECONNABORTED error (113) with no further details, even though I'm using the certificates provided by my browser.

After reading a bit on other tickets about the subject I tried to disable peer validation but still wasn't able to connect to 'google.com' which now leads me to wander if it might be somehow related to the cyphers I'm using (as suggested in the reply to: https://devzone.nordicsemi.com/f/nordic-q-a/68229/nrf9160-unable-to-disable-certificate-validation-when-connecting-to-https).

I'd appreciate some more help with this issue.

Best regards,
Daniel

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Wed, 24 Apr 2024 13:09:07 GMT

It could sound to me like you got the wrong certs for the webpage you try to connect to.

I think that if you go the the webpage in a browser, you can look at the security settings for the webpage and get which certs you need from there.

RE: HTTPS without T-FM and PSA

Daniel Figueira — Wed, 24 Apr 2024 12:22:04 GMT

The HTTPS_client sample also seems to work for me with the configs you provided 👍

I tried to use the HTTPS_client sample to connect to the server used by 'wififund_less5_exer2' (echo.thingy.rocks) with the certificate provided for that lesson (which we've been using in our tests) and I figured out that by null-terminating that certificate like shown on the HTTPS_client sample:

I no longer get the EINVAL error code (22) - which makes sense since I previously did not understand why connect would be returning EINVAL: https://pubs.opengroup.org/onlinepubs/9699919799/functions/connect.html

I still get an ECONNABORTED error (113) - which is not described on the connect() function, but seems to make more sense...

I'll try to look a bit more into it later this week. If I can't manage to connect to 'echo.thingy.rocks' (nordic server) I'll use the server (example.com) and certificates from the HTTPS_client sample instead and see how that goes.

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Tue, 23 Apr 2024 14:47:48 GMT

Worked for me on nrf7002dk_nrf5340_cpuapp now. That is a good sign.

Let me know how your test goes

RE: HTTPS without T-FM and PSA

Daniel Figueira — Mon, 22 Apr 2024 13:49:05 GMT

Hi Sigurd, tomorrow I won't be able to, but Wednesday I will give this a try see how it goes.

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Mon, 22 Apr 2024 12:08:04 GMT

Hi Daniel,

(Optional) To learn about the PSA Crypto API, see Securing IoT products with PSA Certified APIs .

One of the big upsides with the PSA Crypto API is that it should do the same both with and without TF-M, so your code should function the same (if a tad less securely) without TF-M.

So out of the gate, I think that what you try should work.

Can you try our HTTPS Client example without TF-M?
Reason I ask for a sample is because that makes this easier to try and reproduce from my side.
Here is the overlay I used for nrf7002dk_nrf5340_cpuapp.conf, which maybe work:

#
# Copyright (c) 2023 Nordic Semiconductor ASA
#
# SPDX-License-Identifier: LicenseRef-Nordic-5-Clause
#

# General
CONFIG_POSIX_CLOCK=y
CONFIG_SYSTEM_WORKQUEUE_STACK_SIZE=4096
CONFIG_HEAP_MEM_POOL_SIZE=81920
CONFIG_NET_RX_STACK_SIZE=2048

# Optimize Wi-Fi stack to save some memory
CONFIG_NRF700X_RX_NUM_BUFS=16
CONFIG_NRF700X_MAX_TX_AGGREGATION=4

# Wi-Fi
CONFIG_WIFI=y
CONFIG_WIFI_NRF700X=y
CONFIG_WIFI_NRF700X_LOG_LEVEL_ERR=y
CONFIG_WIFI_MGMT_EXT=y
CONFIG_WIFI_CREDENTIALS=y


# Shell
CONFIG_SHELL=y
CONFIG_SHELL_STACK_SIZE=6144

# WPA supplicant
CONFIG_WPA_SUPP=y
CONFIG_WPA_SUPP_LOG_LEVEL_ERR=y

# Zephyr NET Connection Manager connectivity layer
CONFIG_L2_WIFI_CONNECTIVITY=y
CONFIG_L2_WIFI_CONNECTIVITY_AUTO_DOWN=n
CONFIG_L2_WIFI_CONNECTIVITY_AUTO_CONNECT=n

# DNS
CONFIG_DNS_RESOLVER=y
CONFIG_NET_SOCKETS_DNS_TIMEOUT=30000

# NET sockets
CONFIG_NET_NATIVE=y
CONFIG_NET_L2_ETHERNET=y
CONFIG_NET_TCP=y
CONFIG_NET_TCP_WORKQ_STACK_SIZE=2048
CONFIG_NET_UDP=y
CONFIG_NET_SOCKETS_OFFLOAD=n
CONFIG_NET_DHCPV4=y
CONFIG_NET_CONTEXT_SNDTIMEO=y

# TLS networking
CONFIG_NET_SOCKETS_ENABLE_DTLS=n
CONFIG_NET_SOCKETS_TLS_MAX_CONTEXTS=2
CONFIG_NET_SOCKETS_SOCKOPT_TLS=y

# TLS credentials
CONFIG_FLASH=y
Here is the overlay I used for nrf7002dk_nrf5340_cpuapp
CONFIG_FLASH_MAP=y
CONFIG_NVS=y
CONFIG_SETTINGS=y
CONFIG_WIFI_CREDENTIALS_BACKEND_SETTINGS=y
CONFIG_TLS_CREDENTIALS_BACKEND_VOLATILE=y

# mbedTLS
CONFIG_NRF_SECURITY=y
CONFIG_MBEDTLS=y
CONFIG_MBEDTLS_ENABLE_HEAP=y
CONFIG_MBEDTLS_HEAP_SIZE=81920
CONFIG_PSA_WANT_KEY_TYPE_RSA_PUBLIC_KEY=y
CONFIG_PSA_WANT_RSA_KEY_SIZE_2048=y
CONFIG_MBEDTLS_RSA_C=y
CONFIG_MBEDTLS_TLS_LIBRARY=y


CONFIG_WIFI_CREDENTIALS_STATIC=y
CONFIG_WIFI_CREDENTIALS_STATIC_SSID=""
CONFIG_WIFI_CREDENTIALS_STATIC_PASSWORD=""

CONFIG_PM_SINGLE_IMAGE=y

I say "maybe" because I did not get to test it yet. I planned to but then Monday happened and I do not have access to a nRF7002DK until tomorrow.

RE: HTTPS without T-FM and PSA

Sigurd Hellesvik — Fri, 19 Apr 2024 12:51:49 GMT

Hi,

I will look into this and return with more information on Monday.

Regards,
Sigurd Hellesvik