Tls-ondersteuning (Transport Layer Security) in IoT Hub
IoT Hub maakt gebruik van Transport Layer Security (TLS) om verbindingen van IoT-apparaten en -services te beveiligen. Er worden momenteel drie versies van het TLS-protocol ondersteund, namelijk versies 1.0, 1.1 en 1.2.
TLS 1.0 en 1.1 worden beschouwd als verouderd en zijn gepland voor afschaffing. Zie TLS 1.0 en 1.1 voor IoT Hub afgeschaft voor meer informatie. Gebruik TLS 1.2 als enige TLS-versie wanneer u verbinding maakt met IoT Hub om toekomstige problemen te voorkomen.
TLS-certificaat van ioT Hub-server
Tijdens een TLS-handshake presenteert IoT Hub RSA-servercertificaten om clients te verbinden. In het verleden waren de certificaten allemaal geroot van de Baltimore Cybertrust Root CA. Omdat de Baltimore-wortel aan het einde van het leven is, zijn we bezig met het migreren naar een nieuwe hoofdmap met de naam DigiCert Global G2. Deze migratie is van invloed op alle apparaten die momenteel verbinding maken met IoT Hub. Zie IoT TLS-certificaatupdate voor meer informatie.
Hoewel basis-CA-migraties zeldzaam zijn, moet u voor tolerantie in het moderne beveiligingslandschap uw IoT-scenario voorbereiden op het onwaarschijnlijke geval dat een basis-CA is aangetast of een nood-CA-migratie nodig is. We raden u ten zeerste aan dat alle apparaten de volgende drie basis-CA's vertrouwen:
- Baltimore CyberTrust root CA
- DigiCert Global G2-basis-CA
- Microsoft RSA root CA 2017
Zie de details van de Azure-certificeringsinstantie voor koppelingen om deze certificaten te downloaden.
TLS-certificaat voor elliptische curvecryptografie (ECC)-server (preview)
TLS-certificaat van IoT Hub ECC-server is beschikbaar voor openbare preview. Ecc-certificaatvalidatie (met alleen ECC-coderingssuites) biedt een vergelijkbare beveiliging als RSA-certificaten en maakt gebruik van maximaal 40% minder rekenkracht, geheugen en bandbreedte. Deze besparingen zijn belangrijk voor IoT-apparaten vanwege hun kleinere profielen en geheugen en ter ondersteuning van use cases in beperkte omgevingen met netwerkbandbreedte.
We raden u ten zeerste aan dat alle apparaten die ECC gebruiken, de volgende twee basis-CA's vertrouwen:
- DigiCert Global G3-basis-CA
- Microsoft RSA root CA 2017
Zie de details van de Azure-certificeringsinstantie voor koppelingen om deze certificaten te downloaden.
Een voorbeeld van het ECC-servercertificaat van IoT Hub bekijken:
- Maak een nieuwe IoT-hub met de preview-modus ingeschakeld.
- Configureer uw client om alleen ECDSA-coderingssuites op te nemen en RSA-suites uit te sluiten. Dit zijn de ondersteunde coderingssuites voor de openbare preview van het ECC-certificaat:
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
- Verbind uw client met de preview-IoT-hub.
TLS 1.2 afdwingen beschikbaar in bepaalde regio's
Configureer uw IoT Hubs voor extra beveiliging om alleen clientverbindingen toe te staan die gebruikmaken van TLS-versie 1.2 en om het gebruik van coderingssuites af te dwingen. Deze functie wordt alleen ondersteund in deze regio's:
- VS - oost
- VS - zuid-centraal
- VS - west 2
- US Gov - Arizona
- US Gov Virginia (TLS 1.0/1.1-ondersteuning is niet beschikbaar in deze regio- TLS 1.2-afdwinging moet zijn ingeschakeld of het maken van ioT-hubs mislukt)
Als u TLS 1.2-afdwinging wilt inschakelen, volgt u de stappen in Een IoT-hub maken in Azure Portal, met uitzondering van
Kies een regio in de bovenstaande lijst.
Selecteer onder Beheer -> Geavanceerd -> Transport Layer Security (TLS) -> Minimale TLS-versie 1.2. Deze instelling wordt alleen weergegeven voor De IoT-hub die is gemaakt in de ondersteunde regio.
Als u een ARM-sjabloon wilt gebruiken voor het maken, richt u een nieuwe IoT Hub in een van de ondersteunde regio's in en stelt u de minTlsVersion
eigenschap 1.2
in op in de resourcespecificatie:
{
"$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
}
}
]
}
De gemaakte IoT Hub-resource die deze configuratie gebruikt, weigert apparaat- en serviceclients die verbinding proberen te maken met TLS-versies 1.0 en 1.1. Op dezelfde manier wordt de TLS-handshake geweigerd als het ClientHello
bericht geen van de aanbevolen coderingen bevat.
Notitie
De minTlsVersion
eigenschap heeft het kenmerk Alleen-lezen en kan niet worden gewijzigd zodra uw IoT Hub-resource is gemaakt. Het is daarom essentieel dat u uw IoT-apparaten en -services goed test en valideert dat ze compatibel zijn met TLS 1.2 en de aanbevolen coderingen van tevoren.
Na failovers blijft de minTlsVersion
eigenschap van uw IoT Hub effectief in de geografisch gekoppelde regio na een failover.
Coderingssuites
IoT Hubs die zijn geconfigureerd om alleen TLS 1.2 te accepteren, dwingt ook het gebruik van de volgende aanbevolen coderingssuites af:
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
Voor IoT Hubs die niet zijn geconfigureerd voor afdwinging van TLS 1.2, werkt TLS 1.2 nog steeds met de volgende coderingssuites:
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
(Deze codering wordt afgeschaft op 10-01-2022 en wordt niet meer gebruikt voor TLS-handshakes)
Een client kan een lijst met hogere coderingssuites voorstellen die tijdens ClientHello
het gebruik moeten worden gebruikt. Sommige hiervan worden echter mogelijk niet ondersteund door IoT Hub (bijvoorbeeld ECDHE-ECDSA-AES256-GCM-SHA384
). In dit geval zal IoT Hub proberen de voorkeur van de client te volgen, maar uiteindelijk onderhandelen over de coderingssuite met ServerHello
.
TLS-configuratie voor SDK en IoT Edge
Gebruik de onderstaande koppelingen om TLS 1.2 en toegestane coderingen te configureren in SDK's van de IoT Hub-client.
Taal | Versies die TLS 1.2 ondersteunen | Documentatie |
---|---|---|
E | Tag 2019-12-11 of hoger | Koppeling |
Python | Versie 2.0.0 of hoger | Koppeling |
C# | Versie 1.21.4 of hoger | Koppeling |
Java | Versie 1.19.0 of hoger | Koppeling |
NodeJS | Versie 1.12.2 of hoger | Koppeling |
IoT Edge-apparaten kunnen worden geconfigureerd voor het gebruik van TLS 1.2 tijdens de communicatie met IoT Hub. Gebruik hiervoor de documentatiepagina van IoT Edge.
Apparaatverificatie
Na een geslaagde TLS-handshake kan IoT Hub een apparaat verifiëren met behulp van een symmetrische sleutel of een X.509-certificaat. Voor verificatie op basis van certificaten kan dit elk X.509-certificaat zijn, inclusief ECC. IoT Hub valideert het certificaat op basis van de vingerafdruk of certificeringsinstantie (CA) die u opgeeft. Zie Ondersteunde X.509-certificaten voor meer informatie.
Wederzijdse TLS-ondersteuning
Wederzijdse TLS-verificatie zorgt ervoor dat de client het servercertificaat (IoT Hub) verifieert en de server (IoT Hub) het X.509-clientcertificaat of X.509-vingerafdruk verifieert. Autorisatie wordt uitgevoerd door IoT Hub nadat de verificatie is voltooid.
Voor AMQP- en MQTT-protocollen vraagt IoT Hub een clientcertificaat aan in de eerste TLS-handshake. Als er een is opgegeven, verifieert IoT Hub het clientcertificaat en verifieert de client het IoT Hub-certificaat. Dit proces wordt wederzijdse TLS-verificatie genoemd. Wanneer IoT Hub een MQTT-verbindingspakket ontvangt of een AMQP-koppeling wordt geopend, voert IoT Hub autorisatie uit voor de aanvragende client en bepaalt of de client X.509-verificatie vereist. Als wederzijdse TLS-verificatie is voltooid en de client gemachtigd is om verbinding te maken als het apparaat, is dit toegestaan. Als de client echter X.509-verificatie vereist en clientverificatie niet is voltooid tijdens de TLS-handshake, weigert IoT Hub de verbinding.
Wanneer de client voor het eerst een aanvraag indient, controleert IoT Hub bij HTTP-protocol of voor de client X.509-verificatie is vereist en of clientverificatie is voltooid, dan voert IoT Hub autorisatie uit. Als clientverificatie niet is voltooid, weigert IoT Hub de verbinding
Certificaat vastmaken
Het vastmaken en filteren van certificaten van tls-servers (ook wel leaf-certificaten genoemd) en tussenliggende certificaten die zijn gekoppeld aan IoT Hub-eindpunten, wordt sterk afgeraden omdat Microsoft deze certificaten regelmatig met weinig of geen kennisgeving meedeelt. Als u dat wilt, moet u alleen de basiscertificaten vastmaken zoals beschreven in dit Azure IoT-blogbericht.
Tls-maximale onderhandelingen over de lengte van fragmenten (preview)
IoT Hub ondersteunt ook onderhandeling over maximale fragmentlengte van TLS, ook wel onderhandelingen over DE TLS-framegrootte genoemd. Deze functie is beschikbaar voor openbare preview.
Gebruik deze functie om de maximale lengte van tekstfragmenten zonder opmaak op te geven tot een waarde die kleiner is dan de standaardwaarde 2^14 bytes. Zodra er is onderhandeld, beginnen IoT Hub en de client berichten te fragmenteren om ervoor te zorgen dat alle fragmenten kleiner zijn dan de onderhandelde lengte. Dit gedrag is handig voor apparaten met beperkte rekenkracht of geheugen. Zie de officiële TLS-extensiespecificatie voor meer informatie.
Officiële SDK-ondersteuning voor deze openbare preview-functie is nog niet beschikbaar. Aan de slag
- Maak een nieuwe IoT-hub met de preview-modus ingeschakeld.
- Wanneer u OpenSSL gebruikt, roept u SSL_CTX_set_tlsext_max_fragment_length aan om de fragmentgrootte op te geven.
- Verbind uw client met de preview-versie van IoT Hub.