Azure-Functions icon indicating copy to clipboard operation
Azure-Functions copied to clipboard

Can not query API from IoT Device

Open aardrasystems opened this issue 10 months ago • 7 comments

Hi

I am using an Azure Function App for an IoT device (microcontroller + GSM module) to query an API.

Since around 4 AM UK time today, the API has not been accessible from the device, even though it works fine when accessed via a web browser. This suggests the issue is likely related to TLS/SSL or cipher suites, possibly something failing during the handshake. It had been working fine until now.

I am currently running version 4.637.1.23604. Is there any way to roll back to a previous version, possibly one that was active about a week ago? As my device without the API connection can not be controlled.

aardrasystems avatar Apr 01 '25 17:04 aardrasystems

Further to this, I noticed an unscheduled maintenance in the portal with the following ID. Is anyone aware of this?

Tracking ID 4VW0-HRG

aardrasystems avatar Apr 02 '25 07:04 aardrasystems

Can anyone help resolve this issue? It seems there is a TLS handshake problem. I can no longer access my app from the IoT device using TLS 1.2, 1.1, or 1.0, even though they should all be compatible.

This problem arose after the March 31st update.

Is there anyone from the product development team who can assist me?

aardrasystems avatar Apr 07 '25 18:04 aardrasystems

Anyone here who can help me?

aardrasystems avatar Apr 08 '25 19:04 aardrasystems

Let me try to explain here the problem you likely encountered and should be solved now. Within the TLS handshake (ClientHello) the client (IoT device) sends a TLS 'record' version and a 'hello' version. For TLS1.0 these must be both 0x0301. For TLS1.1 they must be both 0x302. For TLS1.2 the record version must be in 0x0300-0x03FF and the hello version 0x0303. For TLS1.3 the record version must be ignored by the server (0x0000-0xFFFF).

Our clients - and likely your IoT devices - connect to a TLS1.2 server and send 0x0300 and 0x0303 which is valid. Since March 31st the server required 0x0303 and 0x0303 which violates the TLS RFCs as far as I can tell. There is nothing a client can do when a server does not implement a protocol properly. Most browsers and libraries set the record and hello version to the same number 0x0303 for TLS1.2 because this was required for TLS1.0 and TLS1.1 too. Clients using such a library were not affected.

godly avatar Apr 18 '25 21:04 godly

@godly

Thanks — we've managed to get our Function Apps working with our IoT devices.

Following up on what you mentioned, our devices have SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2 all enabled. The device was sending 0x0300 and 0x3030.

While the issue with my Function App has now been resolved, I'm still concerned about potential problems when connecting our IoT devices to resources such as IoT Hub and Blob Storage. These services require a minimum of TLS 1.2, whereas our devices have all TLS and SSL versions enabled on the modules.

aardrasystems avatar Apr 19 '25 14:04 aardrasystems

One should expect that all TLS 1.2 servers implement the TLS protocol properly and not change clients which have been working fine for many years.

In case you expect that another service will not implement TLS 1.2 or 1.3 properly you might try to modify the client to always send the same 'record' and 'hello' version during the handshake. This would allow to establish the connection in case a very similar bug is added.

godly avatar Apr 22 '25 20:04 godly

@godly Yes, we aim to update our devices to use only TLS 1.2, but some devices are legacy and cannot be modified. How can we ensure that the server's TLS configuration is not restricting the record version?

aardrasystems avatar Apr 24 '25 08:04 aardrasystems