MicrosoftDocs
Contradicting information on mTLS support
Contradicting information on this page ( IoT Hub doesn't support mutual TLS ) while on this page https://learn.microsoft.com/en-us/azure/iot-hub/iot-hub-tls-support#mutual-tls-support it is said "supported" [Enter feedback here]
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
- ID: e275ce10-660d-4f06-9b9d-abb31940c564
- Version Independent ID: de3b6527-e1fb-93d3-fdb9-3bb5f6958aa7
- Content: Understand how IoT Edge uses certificates for security
- Content Source: articles/iot-edge/iot-edge-certs.md
- Service: iot-edge
- GitHub Login: @jlian
- Microsoft Alias: jlian
@difatkulbayanova Thanks for your feedback! We will investigate and update as appropriate.
Ok, sorry there was some confusion and misunderstanding that I believe have finally (😅) been cleared up. I confirmed that IoT Hub does, in fact, support mTLS. Or, using more technically accurate phrasing, IoT Hub performs a full client-authenticated TLS handshake which verifies that the client has possession of the private key. This happens for both X.509 CA as well as thumbprint (AKA self-signed) authentication.
I've made the edits in the IoT Edge docs and the update should go live today.
Here's the full quote from an IoT Hub dev, emphasis mine:
Authentication of the client doesn't happen at the TLS level, only at the application layer.
This is incorrect. X509 client authentication is performed during the TLS handshake. Authorization is always performed by the application. The wording above would imply we don't even have a compliant TLS implementation. To avoid confusion, all documentation should state that IoT Hub supports "mutual TLS authentication".
[...]
I'm not aware of any formal definition of mutual TLS. "Mutual" does not appear in RFC 5246. There are some semi-relevant references to mutual auth in TLS 1.3 (RFC 8446), however these are related specifically to the new post-handshake authentication extension added in TLS 1.3, which we do not support. Mutual TLS simply implies that client certification authentication is performed on the server and server certificate authentication is performed on the client. There is no de facto understanding that authorization occurs within the bounds of the TLS handshake. This is clearly the prevailing case on HTTP where mTLS is used. Various HTTP methods and paths will be authorized using the previously authenticated principal during the handshake.
For AMQP and MQTT protocols we request a certificate in the initial handshake. If one is provided, mutual[^1] authentication is [completed]. When we later receive an MQTT connect packet or an AMQP link open, we perform authorization for the requested device. If the authenticated (via X509 certificate) principal is authorized to connect as the device, it is allowed. If the requested device requires X509 authentication, and client certificate authentication was not completed during the initial handshake OR the request is over HTTP, then we initiate a new complete TLS handshake. Once that new mutual authentication process is complete, we perform authorization with the authenticated (via X509 certificate) principal.
[^1]: "mutual" assumes client did validation of the server certificate
Looking at the full quote and our docs I think need a slight update to the diagram as well and put the thumbprint verification (an "authorization" that happens after TLS handshake) in a later step:
Hi @jlian,
I saw this open issue. I made a change to the image as described. Take a look at https://github.com/MicrosoftDocs/azure-docs-pr/pull/245065. If it looks correct, I can merge the change.
Thanks, Pat
