Difficulty debugging https POST to microsoft Azure.

[JVantol]

I'm trying to use https POST to deliver data payloads to Azure.

We've done a proof of concept using POSTMAN, and we're certain we've got the right method, correct headers on the request, etc.

Since we're authenticating to Azure using X509 certificates, we open the socket, configure the security tag, set TLS_PEER Veriify to required, set the TLS hostname, and then Send our request to Azure.

The message looks like this (redacted identifiable info)

POST /devices/xxxxxxx/messages/events?api-version=2019-10-01 HTTP/1.1
Content-Type: application/json
Host: some-iot-hub.azure-devices.net
Connection: keep-alive
Content-Length: 65

{"deviceId": "xxxx", "data": "1.0", "ts": "2020-04-16T20:58:32Z"}

This is sent, without error, and then we receive on that socket. I expect to get back something like this:

HTTP/1.1 204 No Content

Content-Length: 0

Server: Microsoft-HTTPAPI/2.0

Date: Thu, 16 Apr 2020 15:14:49 GMT

But instead get zero bytes. Interestingly, deliberately mis-configuring the security tag (specifying a non-existent one) does NOT cause an error during connect, which leads me to believe that something is going wrong with the connect.

Is there a recommended way to debug this sort of problem? I don't really have very good visibility into the Azure end of things, but I know that if I mis-configure the certs with the PC tool, I do get back a response, indicating that the certs are wrong.

What are some options for debugging this? Are there some additional debug options I can turn on to see what might be happening with TLS? It really seems that the data is NOT being sent, but there is no error code returned.

Finally, if need be, I can open a private ticket and post source code and such, but this seems like a problem others might have, so I'll start with Public.

[Didrik Rokhaug]

Hi.

We do not support Server Name Indication (SNI) at this point, which is probably the reason why you connect fails.

One (bad) way to work around that is to disable hostname verification. However, that has some obvious security problems.

Best regards,

Didrik

[JVantol]

We cannot disable SNI, as we don't control the other end. Is there a reason why the connect does not fail, nor does the send? Clearly it isn't working, but no failure is coming back. Is there a way to know for sure that the lack of SNI is causing this failure?

Is there a plan and a timeline to support SNI? Clearly there's awareness of the need, as the interface (socket_hostname_set) is there.

Also per my other ticket # 248033 is there a way to hook wireshark to the modem trace and discern for myself what's going on?

[Didrik Rokhaug]

JVantol said:

Is there a plan and a timeline to support SNI? Clearly there's awareness of the need, as the interface (socket_hostname_set) is there.

 Sadly, I can not comment on that. Questions about future releases should be directed to your Regional Sales Manager.

 

JVantol said:

Also per my other ticket # 248033 is there a way to hook wireshark to the modem trace and discern for myself what's going on?

 As my colleague answered in that ticket, your proposal has been forwarded to our product management team. Other than that, I am again unable to provide further comments.

 

JVantol said:

Is there a way to know for sure that the lack of SNI is causing this failure?

 A modem trace would be the best way to say for sure

[JVantol]

Didrik,

I took a modem trace, and was able to get it decoded by one of your colleagues. I'm pretty much a HTTPS/TLS newbie, so I'll have to spend some time getting up to speed on what it's supposed to look like. If you've got any suggested reference materials for learning the ins and outs of TLS I'm all ears.

Thanks,

Josh