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

  • Artikel

IoT Hub använder TLS (Transport Layer Security) för att skydda anslutningar från IoT-enheter och -tjänster. För närvarande stöds tre versioner av TLS-protokollet, nämligen version 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 Inaktuell 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 presenterar IoT Hub RSA-nyckelade servercertifikat till anslutande klienter. Tidigare var certifikaten alla rotade från Baltimore Cybertrust Root CA. Eftersom Baltimore-roten är i livets slutskede håller vi på att migrera till en ny rot som heter DigiCert Global G2. Den här migreringen påverkar alla enheter som för närvarande ansluter till IoT Hub. Mer information finns i IoT TLS-certifikatuppdatering.

Även om rot-CA-migreringar är sällsynta bör du förbereda IoT-scenariot för den osannolika händelsen att en rotcertifikatutfärdare komprometteras eller om en rot-CA-migrering krävs för nödsituationer. Vi rekommenderar starkt att alla enheter litar på följande tre rotcertifikatutfärdare:

  • Baltimore CyberTrust rot-CA
  • DigiCert Global G2-rotcertifikatutfärdare
  • Microsoft RSA-rotcertifikatutfärdare 2017

Länkar för att ladda ned dessa certifikat finns i Information om Azure Certificate Authority.

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

IoT Hub ECC-serverns TLS-certifikat är tillgängligt för offentlig förhandsversion. Ecc-certifikatverifiering (med endast ECC-chiffersviter) använder upp till 40 % mindre beräkning, minne och bandbredd, men erbjuder liknande säkerhet som RSA-certifikat. 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 nätverksbandbreddsbegränsade miljöer.

Vi rekommenderar starkt att alla enheter som använder ECC litar på följande två rotcertifikatutfärdare:

  • DigiCert Global G3-rotcertifikatutfärdare
  • Microsoft RSA-rotcertifikatutfärdare 2017

Länkar för att ladda ned dessa certifikat finns i Information om Azure Certificate Authority.

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

  1. Skapa en ny IoT-hubb med förhandsgranskningsläget 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 Hub.

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

För extra 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 endast i dessa regioner:

  • USA, östra
  • USA, södra centrala
  • Västra USA 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 Hub-skapandet)

Om du vill aktivera TLS 1.2-tillämpning följer du stegen i Skapa IoT-hubb i Azure-portalen, 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.

    Screenshot showing how to turn on TLS 1.2 enforcement during IoT hub creation

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 med 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 ClientHello om meddelandet inte visar någon av de rekommenderade chifferna.

Kommentar

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 chiffer 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 framtvingar också användning 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 inte stöds av IoT Hub (till exempel ECDHE-ECDSA-AES256-GCM-SHA384). I det här fallet kommer IoT Hub att försöka följa klientens inställningar, men så småningom förhandla 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 Tagga 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 för att använda TLS 1.2 vid kommunikation med IoT Hub. För detta ändamål använder du IoT Edge-dokumentationssidan.

Enhetsautentisering

Efter ett lyckat TLS-handslag 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 validerar 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 att servern (IoT Hub) autentiserarX.509-klientcertifikatet eller X.509-tumavtrycket. Auktorisering utförs av IoT Hub när autentiseringen har slutförts.

För AMQP- och MQTT-protokoll begär IoT Hub ett klientcertifikat i den första TLS-handskakningen. Om ett sådant 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 utför IoT Hub auktorisering. Om klientautentiseringen inte har slutförts avvisar IoT Hub anslutningen

Fäst certifikat

Att fästa och filtrera TLS-servercertifikat (ä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 har också stöd för förhandlingar om maximal fragmentlängd för TLS, vilket ibland kallas TLS-ramstorleksförhandling. Den här funktionen är en allmänt tillgänglig förhandsversion.

Använd den här funktionen om du vill ange den maximala fragmentlängden i klartext till ett värde som är mindre än standardvärdet 2^14 byte. När det har förhandlats börjar IoT Hub och klienten 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äkning 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 av IoT Hub.

Nästa steg