Native TLS support in HL7802

I know I suggested this before but I would like to once again bring up the support for secure client with HL7802. This module supports it natively and the only thing to enable secure client (besides uploading the correct certificates) is to send one different byte in the +KTCPCFG command.
I propose this:

  • Add “CELLULAR_SOCKET_PROTOCOL_TLS” to CellularSocketProtocol_t.
  • Change “buildSocketConfig” function in cellular_hl7802_api.c to support the new “CELLULAR_SOCKET_PROTOCOL_TLS” (line 528).
  • Send “AT+KTCPCFG=%u,3,(…)” instead of “AT+KTCPCFG=%u,0,(…)” when protocol is TLS (line 550).
  • Add “TCP_NOTIF_SSL_CONNECTION_ERROR” with a value of “13” to the enumeration “tcpConnectionFailure_t” in cellular_hl7802.h.
  • Add the new “TCP_NOTIF_SSL_CONNECTION_ERROR” as a case label to the function “handleTcpNotif” in cellular_hl7802_urc_handler.c right under the “TCP_NOTIF_TCP_CONNECTION_ERROR” label.

This will enable basic TLS support when using modem’s built-in functionality. All other cases can lead to some “unsupported” error message until they are implemented.

@kaktus
Thank you for your suggestion.
We would also consider that other FreeRTOS supported modem should be able to offload the TLS with this method.
I will try the proposal and provide more information for discussion later.

Great. To be honest, selecting cipher suite number when opening socket would be great too. Because there are only 7 possible cipher suites on HL7802, a match has to be found with what the server supports. Otherwise, the secure connection fails to establish.
In my case, leaving the default “any” cipher suite fails with Azure IoT hub but selecting a specific one from the same pool succeeds, for some reason…

In general, TLS offload can cause many headaches when TLS cipher suites are deprecated. Cellular modem firmware is usually infrequently updated by manufacturers. If possible for your application, it is probably best use a TLS stack which you have the ability to update rather than offload to the module firmware.

Completely agree with that. Shame our current hardware is too constrained to do that.

@kaktus
Sorry for very late reply to this thread.
Currently, we don’t have enough resource to propose and implement the TLS offload feature in the short time. If you already have an implementation, it is suggested to create a PR in the cellular interface repository. We would also discuss over this PR with you.