TLS-stöd (Transport Layer Security) i IoT Hub

IoT Hub använder TLS (Transport Layer Security) för att skydda anslutningar från IoT-enheter och -tjänster. Tre versioner av TLS-protokollet stöds för närvarande, nämligen versionerna 1.0, 1.1 och 1.2.

TLS 1.0 och 1.1 anses vara äldre och planeras för utfasning. Mer information finns i Ta bort TLS 1.0 och 1.1 för IoT Hub. Undvik framtida problem genom att använda TLS 1.2 som den enda TLS-versionen när du ansluter till IoT Hub.

IoT Hub-serverns TLS-certifikat

Under en TLS-handskakning visar IoT Hub RSA-nyckelade servercertifikat till anslutande klienter. Dess rot är Baltimore Cybertrust Root CA. Eftersom Baltimore-roten är i slutet av livet, kommer vi att migrera till en ny rot som heter DigiCert Global G2. Den här ändringen påverkar alla enheter som för närvarande ansluter till IoT Hub. Information om hur du förbereder migreringen finns i IoT TLS-certifikatuppdatering.

Elliptic Curve Cryptography (ECC) server TLS-certifikat (förhandsversion)

IoT Hub ECC-serverns TLS-certifikat är tillgängligt för offentlig förhandsversion. ECC-certifikatvalidering (med endast ECC-chiffersviter) erbjuder liknande säkerhet som RSA-certifikat, men använder upp till 40 % mindre beräkning, minne och bandbredd. Dessa besparingar är viktiga för IoT-enheter på grund av deras mindre profiler och minne och för att stödja användningsfall i miljöer med begränsad nätverksbandbredd. ECC-servercertifikatets rot är DigiCert Global Root G3.

Så här förhandsgranskar du IoT Hub ECC-servercertifikat:

1. Skapa en ny IoT-hubb med förhandsgranskningsläge aktiverat.
2. Konfigurera klienten så att den endast innehåller ECDSA-chiffersviter och exkludera eventuella RSA-paket. Det här är de chiffersviter som stöds för den offentliga förhandsversionen av ECC-certifikatet:
   • 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. Anslut klienten till förhandsversionen av IoT-hubben.

TLS 1.2-tillämpning tillgänglig i utvalda regioner

För ökad säkerhet konfigurerar du dina IoT Hubs så att de endast tillåter klientanslutningar som använder TLS version 1.2 och framtvingar användningen av chiffersviter. Den här funktionen stöds bara i dessa regioner:

• East US
• USA, södra centrala
• USA, västra 2
• US Gov, Arizona
• US Gov Virginia (TLS 1.0/1.1-stöd är inte tillgängligt i den här regionen – TLS 1.2-tvingande måste aktiveras eller så misslyckas IoT-hubbens skapande)

Om du vill aktivera TLS 1.2-tillämpning följer du stegen i Skapa IoT-hubb i Azure Portal, förutom

• Välj en region från en i listan ovan.

• Under Hantering –> Avancerat –> TLS (Transport Layer Security) –> Lägsta TLS-version väljer du 1.2. Den här inställningen visas bara för IoT Hub som skapats i regionen som stöds.

  

Om du vill använda ARM-mallen för att skapa etablerar du en ny IoT Hub i någon av de regioner som stöds och anger minTlsVersion egenskapen till 1.2 i resursspecifikationen:

{
    "$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
            }
        }
    ]
}

Den skapade IoT Hub resursen som använder den här konfigurationen nekar enhets- och tjänstklienter som försöker ansluta med TLS-versionerna 1.0 och 1.1. På samma sätt nekas TLS-handskakningen om meddelandet ClientHello inte visar någon av de rekommenderade chiffreringarna.

Anteckning

Egenskapen minTlsVersion är skrivskyddad och kan inte ändras när din IoT Hub resurs har skapats. Därför är det viktigt att du testar och verifierar att alla dina IoT-enheter och -tjänster är kompatibla med TLS 1.2 och de rekommenderade chiffreringarna i förväg.

Vid redundans fortsätter egenskapen för minTlsVersion din IoT Hub att gälla i den geo-kopplade regionen efter redundansväxlingen.

Chiffersviter

IoT Hubs som har konfigurerats för att endast acceptera TLS 1.2 tillämpar också användningen av följande rekommenderade chiffersviter:

• 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

För IoT Hubs som inte har konfigurerats för TLS 1.2-tillämpning fungerar TLS 1.2 fortfarande med följande chiffersviter:

• 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(Detta chiffer kommer att vara inaktuellt den 10/01/2022 och kommer inte längre att användas för TLS-handskakningar)

En klient kan föreslå en lista över högre chiffersviter som ska användas under ClientHello. Vissa av dem kanske dock inte stöds av IoT Hub (till exempel ECDHE-ECDSA-AES256-GCM-SHA384). I det här fallet försöker IoT Hub följa klientens preferenser, men så småningom förhandlar du ned chiffersviten med ServerHello.

TLS-konfiguration för SDK och IoT Edge

Använd länkarna nedan för att konfigurera TLS 1.2 och tillåtna chiffer i IoT Hub klient-SDK:er.

Språk	Versioner som stöder TLS 1.2	Dokumentation
C	Tagg 2019-12-11 eller senare	Länk
Python	Version 2.0.0 eller senare	Länk
C#	Version 1.21.4 eller senare	Länk
Java	Version 1.19.0 eller senare	Länk
NodeJS	Version 1.12.2 eller senare	Länk

IoT Edge enheter kan konfigureras att använda TLS 1.2 när de kommunicerar med IoT Hub. Använd därför IoT Edge-dokumentationssidan.

Enhetsautentisering

Efter en lyckad TLS-handskakning kan IoT Hub autentisera en enhet med hjälp av en symmetrisk nyckel eller ett X.509-certifikat. För certifikatbaserad autentisering kan detta vara valfritt X.509-certifikat, inklusive ECC. IoT Hub verifierar certifikatet mot det tumavtryck eller certifikatutfärdare (CA) som du anger. Mer information finns i X.509-certifikat som stöds.

Ömsesidigt TLS-stöd

Ömsesidig TLS-autentisering säkerställer att klienten autentiserar servercertifikatet (IoT Hub) och servern (IoT Hub) autentiserarX.509-klientcertifikatet eller X.509-tumavtrycket. Auktorisering utförs av IoT Hub när autentiseringen är klar.

För AMQP- och MQTT-protokoll begär IoT Hub ett klientcertifikat i den första TLS-handskakningen. Om en av dem anges autentiserar IoT Hub klientcertifikatet och klienten autentiserar IoT Hub certifikatet. Den här processen kallas ömsesidig TLS-autentisering. När IoT Hub tar emot ett MQTT-anslutningspaket eller en AMQP-länk öppnas, utför IoT Hub auktorisering för den begärande klienten och avgör om klienten kräver X.509-autentisering. Om ömsesidig TLS-autentisering slutfördes och klienten har behörighet att ansluta som enhet tillåts den. Men om klienten kräver X.509-autentisering och klientautentiseringen inte slutfördes under TLS-handskakningen avvisar IoT Hub anslutningen.

När klienten gör sin första begäran för HTTP-protokollet kontrollerar IoT Hub om klienten kräver X.509-autentisering och om klientautentiseringen har slutförts IoT Hub auktorisering. Om klientautentiseringen inte slutfördes avvisar IoT Hub anslutningen

Fäst certifikat

Certifikat som fäster och filtrerar TLS-servercertifikaten (även kallade lövcertifikat) och mellanliggande certifikat som är associerade med IoT Hub slutpunkter rekommenderas inte eftersom Microsoft ofta rullar dessa certifikat med liten eller ingen varsel. Om du måste kan du bara fästa rotcertifikaten enligt beskrivningen i det här Azure IoT-blogginlägget.

Förhandlingar om maximal fragmentlängd för TLS (förhandsversion)

IoT Hub stöder även förhandlingar om maximal fragmentlängd för TLS, vilket ibland kallas förhandlingar om TLS-ramstorlek. Den här funktionen är en allmänt tillgänglig förhandsversion.

Använd den här funktionen för att ange den maximala fragmentlängden i klartext till ett värde som är mindre än standardvärdet 2^14 byte. När du har förhandlat IoT Hub och klienten börjar fragmentera meddelanden för att säkerställa att alla fragment är mindre än den förhandlade längden. Det här beteendet är användbart för beräknings- eller minnesbegränsade enheter. Mer information finns i den officiella TLS-tilläggsspecifikationen.

Det officiella SDK-stödet för den här funktionen för offentlig förhandsversion är ännu inte tillgängligt. Så här kommer du igång

1. Skapa en ny IoT-hubb med förhandsgranskningsläget aktiverat.
2. När du använder OpenSSL anropar du SSL_CTX_set_tlsext_max_fragment_length för att ange fragmentstorleken.
3. Anslut klienten till förhandsversionen IoT Hub.

Nästa steg

• Mer information om IoT Hub säkerhets- och åtkomstkontroll finns i Kontrollera åtkomst till IoT Hub.
• Mer information om hur du använder X509-certifikat för enhetsautentisering finns i Enhetsautentisering med X.509 CA-certifikat