Prise en charge de TLS (Transport Layer Security) dans IoT Hub

IoT Hub utilise le protocole TLS (Transport Layer Security) pour sécuriser les connexions provenant d’appareils et de services IoT. Trois versions du protocole TLS sont actuellement prises en charge, à savoir les versions 1.0, 1.1 et 1.2.

Les protocoles TLS 1.0 et 1.1 sont considérés comme hérités et leur obsolescence est planifiée. Pour plus d’informations, consultez Dépréciation de TLS 1.0 et 1.1 pour IoT Hub. Pour éviter tout problème futur, utilisez TLS 1.2 comme seule version TLS lors de la connexion à IoT Hub.

Certificat TLS du serveur d’IoT Hub

Lors d’une négociation TLS, IoT Hub présente des certificats de serveur à clé RSA pour connecter des clients. Dans le passé, les certificats étaient tous enracinés à partir de l’autorité de certification racine Baltimore Cybertrust. Étant donné que la racine Baltimore est à en fin de vie, nous sommes en train de migrer vers une nouvelle racine appelée DigiCert Global G2. Cette migration a un impact sur tous les appareils qui se connectent actuellement à IoT Hub. Pour plus d’informations, consultez mise à jour de certificat TLS IoT.

Bien que les migrations d’autorité de certification racine soient rares, pour la résilience dans le paysage de sécurité moderne, vous devez préparer votre scénario IoT pour l’événement peu probable qu’une autorité de certification racine est compromise ou qu’une migration d’autorité de certification racine d’urgence est nécessaire. Nous vous recommandons vivement d’approuver les trois autorités de certification racines suivantes :

• Baltimore CyberTrust racine CA
• Autorité de certification racine DigiCert Global G2
• Autorité de certification racine Microsoft RSA 2017

Pour obtenir des liens vers le téléchargement de ces certificats, consultez détails de l’autorité de certification Azure.

Certificat TLS (version préliminaire) du serveur ECC (Elliptic Curve Cryptography)

Le certificat TLS du serveur ECC d’IoT Hub est disponible en préversion publique. Tout en offrant une sécurité similaire aux certificats RSA, la validation des certificats ECC (avec les suites de chiffrement exclusivement ECC) utilise jusqu’à 40 % moins de calcul, de mémoire et de bande passante. Ces économies sont importantes pour les appareils IoT en raison de leur profil et de leur mémoire plus petits, et pour prendre en charge les cas d’usage dans des environnements où la bande passante est limitée.

Nous recommandons vivement que tous les appareils utilisant ECC approuvent les deux autorités de certification racine suivantes :

• Autorité de certification racine DigiCert Global G3
• Autorité de certification racine Microsoft RSA 2017

Pour obtenir des liens vers le téléchargement de ces certificats, consultez détails de l’autorité de certification Azure.

Pour afficher un aperçu du certificat de serveur ECC d’IoT Hub :

1. Créez un hub IoT avec le mode aperçu activé.
2. Configurez votre client pour qu’il inclue uniquement des suites de chiffrement ECDSA et exclue toute suite RSA. Les suites de chiffrement prises en charge pour la préversion publique du certificat ECC sont les suivantes :
   • TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
   • TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
   • TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
   • TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
3. Connectez votre client à la préversion d’IoT Hub.

TLS 1.2 n’est disponible que dans certaines régions

Pour renforcer la sécurité, configurez vos hubs IoT pour autoriser uniquement les connexions client qui utilisent la version 1.2 du protocole TLS et pour appliquer l’utilisation des suites de chiffrement. Cette fonctionnalité n'est prise en charge que dans ces régions :

• USA Est
• États-Unis - partie centrale méridionale
• USA Ouest 2
• Gouvernement des États-Unis – Arizona
• US Gov Virginie (La prise en charge de TLS 1.0/1.1 n’est pas disponible dans cette région. L’application de TLS 1.2 doit être activée, sinon la création d’un hub IoT échoue.)

Pour activer l’application de TLS 1.2, suivez les étapes décrites dans Créer un hub IoT dans Portail Azure, sauf

• Choisissez une région dans la liste ci-dessus.

• Sous Gestion -> Avancé -> Protocole TLS -> Version TLS minimale, sélectionnez 1.2. Ce paramètre s’affiche uniquement pour les hubs IoT créés dans une région prise en charge.

  

Afin d’utiliser le modèle ARM pour la création, approvisionnez un nouveau hub IoT dans l’une des régions prises en charge et définissez la propriété minTlsVersion sur 1.2 dans la spécification de ressource :

{
    "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
    "contentVersion": "1.0.0.0",
    "resources": [
        {
            "type": "Microsoft.Devices/IotHubs",
            "apiVersion": "2020-01-01",
            "name": "<provide-a-valid-resource-name>",
            "location": "<any-of-supported-regions-below>",
            "properties": {
                "minTlsVersion": "1.2"
            },
            "sku": {
                "name": "<your-hubs-SKU-name>",
                "tier": "<your-hubs-SKU-tier>",
                "capacity": 1
            }
        }
    ]
}

La ressource IoT Hub créée à l’aide de cette configuration refusera les clients d’appareil et de service qui tentent de se connecter à l’aide des versions 1.0 et 1.1 du protocole TLS. De même, la négociation TLS est refusée si le message ClientHello ne liste aucun des chiffrements recommandés.

Notes

La propriété minTlsVersion est en lecture seule et ne peut pas être modifiée une fois votre ressource IoT Hub créée. C’est pourquoi il est essentiel de tester et de valider correctement que tous vos appareils et services IoT sont compatibles avec le protocole TLS 1.2 et les chiffrements recommandés au préalable.

Lors des basculements, la propriété minTlsVersion de votre IoT Hub reste effective dans la région jumelée géographiquement après le basculement.

Suites de chiffrement

Les hubs IoT configurés pour accepter uniquement TLS 1.2 appliquent également l’utilisation des suites de chiffrement recommandées suivantes :

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384

Pour les hubs IoT non configurés pour l’application de TLS 1.2, ce protocole fonctionne quand même avec les suites de chiffrement suivantes :

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA(ce chiffrement sera déconseillé le 10/01/2022 et ne sera plus utilisé pour les liaisons TLS)

Un client peut suggérer une liste de suites de chiffrement plus élevées à utiliser pendant ClientHello. Toutefois, certaines d’entre elles peuvent ne pas être prises en charge par IoT Hub (par exemple, ECDHE-ECDSA-AES256-GCM-SHA384). Dans ce cas, IoT Hub tente de suivre la préférence du client, mais finit par négocier seulement la suite de chiffrement avec ServerHello.

Configuration TLS pour le Kit de développement logiciel (SDK) et IoT Edge

Utilisez les liens ci-dessous pour configurer TLS 1.2 et les chiffrements autorisés dans les Kits de développement logiciel (SDK) clients IoT Hub.

Langage	Versions prenant en charge TLS 1.2	Documentation
C	Balise 2019-12-11 ou ultérieure	Lien
Python	Version 2.0.0 ou ultérieure	Lien
C#	Version 1.21.4 ou ultérieure	Lien
Java	Version 1.19.0 ou ultérieure	Lien
NodeJS	Version 1.12.2 ou ultérieure	Lien

Les appareils IoT Edge peuvent être configurés pour utiliser TLS 1.2 lors des communications avec IoT Hub. À cet effet, consultez la page de documentation d’IoT Edge.

Authentification des appareils

Après l’établissement de la liaison TLS, IoT Hub peut authentifier un appareil à l’aide d’une clé symétrique ou d’un certificat X.509. Pour l’authentification par certificat, il peut s’agir de n’importe quel certificat X.509, y compris ECC. IoT Hub valide le certificat par rapport à l’empreinte ou à l’autorité de certification (CA) que vous fournissez. Pour plus d’informations, consultez Certificats X.509 pris en charge.

Prise en charge du protocole Mutual TLS

L’authentification mutuelle TLS garantit que le client authentifie le certificat du serveur (IoT Hub) et que le serveur (IoT Hub) authentifie le certificat client X.509 ou l’empreinte X.509. L’autorisation est effectuée par IoT Hub une fois l’authentification terminée.

Pour les protocoles AMQP et MQTT, IoT Hub demande un certificat client dans la négociation TLS initiale. Si un certificat est fourni, IoT Hub authentifie le certificat client, et le client authentifie le certificat IoT Hub. Ce processus est appelé authentification TLS mutuelle. Chaque fois qu’IoT Hub reçoit un paquet de connexion MQTT ou qu’un lien AMQP s’ouvre, IoT Hub effectue l’autorisation pour le client demandeur et détermine si le client a besoin d’une authentification X.509. Si l’authentification TLS mutuelle a été effectuée et que le client est autorisé à se connecter en tant qu’appareil, ce dernier est autorisé. Toutefois, si le client nécessite une authentification X.509 et que l’authentification du client n’a pas été effectuée pendant la négociation TLS, IoT Hub rejette la connexion.

Pour le protocole HTTP, lorsque le client effectue sa première demande, IoT Hub vérifie si le client nécessite l’authentification X.509 et si l’authentification du client a été terminée, IoT Hub effectue l’autorisation. Si l’authentification du client n’a pas été terminée, IoT Hub rejette la connexion

Épinglage de certificat

L’épinglage et le filtrage des certificats de serveur TLS (également appelés certificats feuilles) et les certificats intermédiaires associés aux points de terminaison IoT Hub sont fortement déconseillés, car Microsoft déploie fréquemment ces certificats avec peu ou pas de préavis. Si vous devez le faire, épinglez uniquement les certificats racines comme décrit dans ce billet de blog Azure IoT.

Négociation de la longueur maximale des fragments TLS (préversion)

IoT Hub prend également en charge la négociation de longueur maximale des fragments TLS, parfois appelée négociation de la taille de images TLS. Cette fonctionnalité est en version préliminaire publique.

Utilisez cette fonctionnalité pour spécifier la longueur maximale du fragment de texte en clair sur une valeur inférieure à 2^14 octets par défaut. Une fois la négociation terminée, IoT Hub et le client commencent à fragmenter les messages pour s’assurer que tous les fragments sont plus petits que la longueur négociée. Ce comportement est utile pour le calcul ou les appareils ayant une mémoire restreinte. Pour plus d’informations, consultez la spécification officielle de l’extension TLS.

La prise en charge officielle du Kit de développement logiciel (SDK) pour cette fonctionnalité d’évaluation publique n’est pas encore disponible. Pour commencer

1. Créez un hub IoT avec le mode aperçu activé.
2. Quand vous utilisez OpenSSL, appelez SSL_CTX_set_tlsext_max_fragment_length pour spécifier la taille du fragment.
3. Connectez votre client à la préversion d’IoT Hub.

Étapes suivantes

• Pour en savoir plus sur la sécurité et le contrôle d’accès d’IoT Hub, consultez Contrôler l’accès à IoT Hub.
• Pour en savoir plus sur l’utilisation du certificat X.509 pour l’authentification des appareils, consultez Authentification des appareils à l’aide de certificats d’autorité de certification X.509.