[Technical Question] Security: Check root certificate on device-to-cloud connection

[SymbioticKilla]

Hi,

I have a question about extra security check... Do I need to secure the connection from device to my IoTHub by checking the root certificate for example? Does it bring more security to ensure that device doesn't send any data to non-microsoft endpoint? If yes, do you have any code example for this approach?

Thanks!

[timtay-microsoft]

Hi @SymbioticKilla. When a device connects to IoT hub, the connection will be secured for you by this SDK regardless of authentication type used. When you establish the device-to-cloud connection, both the SDK and the IoT hub will check each-other's certificates to ensure the connection is secure before sending any application data. You do not need to additionally check the device's root cert on your own.

[SymbioticKilla]

Hi @timtay-microsoft,

thank you for the answer! Here is an article about DNS spoofing: https://techcommunity.microsoft.com/t5/fasttrack-for-azure/trusting-the-cloud-from-a-device-perspective/ba-p/2114245

You have mentioned that SDK checks IoTHub(cloud) certificate. Is this article obsolete?

[timtay-microsoft]

From the article:

Most IoT Hub SDKs only validate that the Root Certificates match the expected one (as mentioned before: Baltimore Cybertrust Root CA) while not enforcing Intermediate Certificates.

So the article is correct. The SDKs do validate the IoT Hub's certificate when establishing the connection. The article is more about if/when you should also check the intermediate certificates.

Overall, the document is correct. It is more secure to check the intermediate certificates as well when establishing the connection. However, it isn't usually feasible to do that since intermediate certs can change over time and the Hub team doesn't notify you ahead of time if/when this will happen as far as I know. That means that, if you start requiring a check of the intermediate cert when connecting, you run the risk of the intermediate cert changing without your knowledge and the device being unable to connect again until you update the device's cert store.

The root certificate, by comparison, is valid for the next 10+ years and the Hub team will notify you ahead of time when it will be changed.

[SymbioticKilla]

Thanks! Sorry for not mentioning about intermediate certifacate check in my first post. Is there any property of intermediate certificate that remains the same after update and can not be used by other except Microsoft?

[timtay-microsoft]

As far as I'm aware, the only shared property of every intermediate cert of your Hub is that it is signed by the current root certificate. That is why we generally recommend users only validate the root cert when connecting.

[SymbioticKilla]

@timtay-microsoft Thank you! Can you give more information about "The SDKs do validate the IoT Hub's certificate". What kind of validation? Do you validate thumbprint of Root CA?

[timtay-microsoft]

To be more specific, the SDK will perform a TLS handshake with IoT hub when connecting. It will vary a bit from device to device since the SDK will use whatever TLS version is configured on your device (usually version 1.2), but the broad strokes are generally the same. This document does a good job explaining what a typical TLS handshake entails for both version 1.2 and 1.3.

The only point to add here is that the SDK will automatically load the trusted certificates from your device's trusted certificate store. That means you don't need to instantiate a device client instance with the Hub's root certificate to get this TLS handshake. You just need to instantiate it with your device's connection string (SAS based authentication) or with your device's private key (X509 based authentication).

[SymbioticKilla]

We are using X509 thumbprint authentication method. Is it used only for device authentication or also for message encryption? If not, we can at least check the root certificate of IoTHub to prevent DNS spoofing, I guess.

[timtay-microsoft]

To be clear, when you use AMQP or MQTT, the TLS handshake that happens upon each connection will ensure that all messages sent on that connection are encrypted. HTTP is a bit different since a single connection is established per message, but each HTTP connection still does the TLS handshake to ensure that message is encrypted.

[SymbioticKilla]

I'm little bit confused. If SDK checks trusted CA like the browsers do, there is no possibility to issue a certificate by Let's Encrypt e.g. with the same domain. The article just describes Zero Trust possibility? There is actual almost no security improvement with extra intermediate checks.