Obsługa protokołu Transport Layer Security (TLS) w usłudze IoT Hub

Usługa IoT Hub używa protokołu Transport Layer Security (TLS) do zabezpieczania połączeń z urządzeń i usług IoT. Obecnie obsługiwane są trzy wersje protokołu TLS, czyli wersje 1.0, 1.1 i 1.2.

Protokoły TLS 1.0 i 1.1 są uznawane za starsze i planowane do wycofania. Aby uzyskać więcej informacji, zobacz Przestarzałe protokoły TLS 1.0 i 1.1 dla usługi IoT Hub. Aby uniknąć przyszłych problemów, użyj protokołu TLS 1.2 jako jedynej wersji protokołu TLS podczas nawiązywania połączenia z usługą IoT Hub.

Certyfikat TLS serwera usługi IoT Hub

Podczas uzgadniania protokołu TLS usługa IoT Hub prezentuje certyfikaty serwera z kluczem RSA do łączenia klientów. W przeszłości wszystkie certyfikaty zostały zakorzenione z głównego urzędu certyfikacji Baltimore Cybertrust. Ponieważ root Baltimore jest na koniec życia, jesteśmy w trakcie migracji do nowego katalogu głównego o nazwie DigiCert Global G2. Ta migracja ma wpływ na wszystkie urządzenia, które obecnie łączą się z usługą IoT Hub. Aby uzyskać więcej informacji, zobacz IoT TLS certificate update (Aktualizacja certyfikatu protokołu TLS IoT).

Chociaż migracje głównego urzędu certyfikacji są rzadkie, aby zapewnić odporność w nowoczesnym środowisku zabezpieczeń, należy przygotować scenariusz IoT pod kątem mało prawdopodobnego zdarzenia, że główny urząd certyfikacji jest naruszony lub konieczne jest awaryjne migracji głównego urzędu certyfikacji. Zdecydowanie zalecamy, aby wszystkie urządzenia ufały następującym trzem głównym urzędom certyfikacji:

  • Główny urząd certyfikacji Baltimore CyberTrust
  • Globalny urząd certyfikacji G2 firmy DigiCert
  • Główny urząd certyfikacji RSA firmy Microsoft 2017

Aby uzyskać linki do pobierania tych certyfikatów, zobacz Szczegóły urzędu certyfikacji platformy Azure.

Certyfikat TLS serwera Elliptic Curve Cryptography (ECC) (wersja zapoznawcza)

Certyfikat PROTOKOŁU TLS serwera ECC usługi IoT Hub jest dostępny w publicznej wersji zapoznawczej. Oferując podobne zabezpieczenia do certyfikatów RSA, weryfikacja certyfikatu ECC (z zestawami szyfrów tylko ecC) wykorzystuje do 40% mniej mocy obliczeniowej, pamięci i przepustowości. Te oszczędności są ważne w przypadku urządzeń IoT ze względu na ich mniejsze profile i pamięć oraz obsługę przypadków użycia w środowiskach ograniczonych przepustowości sieci.

Zdecydowanie zalecamy, aby wszystkie urządzenia korzystające z usługi ECC ufały następującym głównym urzędom certyfikacji:

  • Globalny urząd certyfikacji G3 firmy DigiCert
  • Główny urząd certyfikacji RSA firmy Microsoft 2017

Aby uzyskać linki do pobierania tych certyfikatów, zobacz Szczegóły urzędu certyfikacji platformy Azure.

Aby wyświetlić podgląd certyfikatu serwera ECC usługi IoT Hub:

  1. Utwórz nowe centrum IoT z włączonym trybem podglądu.
  2. Skonfiguruj klienta tak, aby zawierał tylko pakiety szyfrowania ECDSA i wykluczyć wszystkie te. Są to obsługiwane zestawy szyfrowania dla publicznej wersji zapoznawczej certyfikatu ECC:
    • 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. Połączenie klienta do centrum IoT w wersji zapoznawczej.

Wymuszanie protokołu TLS 1.2 dostępne w wybranych regionach

Aby zapewnić dodatkowe zabezpieczenia, skonfiguruj usługi IoT Hubs tak, aby zezwalały na połączenia klienckie korzystające z protokołu TLS w wersji 1.2 i wymuszały korzystanie z zestawów szyfrowania. Ta funkcja jest obsługiwana tylko w następujących regionach:

  • Wschodnie stany USA
  • South Central US
  • Zachodnie stany USA 2
  • US Gov Arizona
  • US Gov Virginia (obsługa protokołu TLS 1.0/1.1 nie jest dostępna w tym regionie — wymuszanie protokołu TLS 1.2 musi być włączone lub tworzenie centrum IoT kończy się niepowodzeniem)

Aby włączyć wymuszanie protokołu TLS 1.2, wykonaj kroki opisane w artykule Tworzenie centrum IoT w witrynie Azure Portal, z wyjątkiem

  • Wybierz region z jednej na powyższej liście.

  • W obszarze Zarządzanie —> zaawansowane —> Transport Layer Security (TLS) —> minimalna wersja protokołu TLS wybierz pozycję 1.2. To ustawienie jest wyświetlane tylko dla centrum IoT utworzonego w obsługiwanym regionie.

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

Aby użyć szablonu usługi ARM do utworzenia, aprowizuj nowe centrum IoT Hub w dowolnym z obsługiwanych regionów i ustaw minTlsVersion właściwość na wartość 1.2 w specyfikacji zasobu:

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

Utworzony zasób usługi IoT Hub korzystający z tej konfiguracji odmówi klientom urządzeń i usług, którzy próbują nawiązać połączenie przy użyciu protokołu TLS w wersji 1.0 i 1.1. Podobnie uzgadnianie protokołu TLS zostanie odrzucone, jeśli ClientHello komunikat nie wyświetli żadnej z zalecanych szyfrów.

Uwaga

Właściwość minTlsVersion jest tylko do odczytu i nie można jej zmienić po utworzeniu zasobu usługi IoT Hub. Dlatego ważne jest, aby prawidłowo przetestować i zweryfikować, czy wszystkie urządzenia i usługi IoT są zgodne z protokołem TLS 1.2 i zalecanymi szyframi z wyprzedzeniem.

Po przejściu minTlsVersion w tryb failover właściwość usługi IoT Hub pozostanie skuteczna w regionie sparowanym geograficznie po przejściu w tryb failover.

Zestawy szyfrowania

Usługi IoT Hubs skonfigurowane do akceptowania tylko protokołu TLS 1.2 wymuszają również użycie następujących zalecanych zestawów szyfrowania:

  • 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

W przypadku usługi IoT Hubs nie skonfigurowano wymuszania protokołu TLS 1.2 protokół TLS 1.2 nadal działa z następującymi zestawami szyfrowania:

  • 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(Ten szyfr zostanie wycofany w dniu 10.01.2022 r. i nie będzie już używany do uzgadniania protokołu TLS)

Klient może zasugerować listę wyższych zestawów szyfrowania do użycia podczas .ClientHello Jednak niektóre z nich mogą nie być obsługiwane przez usługę IoT Hub (na przykład ECDHE-ECDSA-AES256-GCM-SHA384). W takim przypadku usługa IoT Hub spróbuje postępować zgodnie z preferencjami klienta, ale ostatecznie negocjuje pakiet szyfrowania za pomocą polecenia ServerHello.

Konfiguracja protokołu TLS dla zestawu SDK i usługi IoT Edge

Skorzystaj z poniższych linków, aby skonfigurować protokół TLS 1.2 i dozwolone szyfry w zestawach SDK klienta usługi IoT Hub.

Język Wersje obsługujące protokół TLS 1.2 Dokumentacja
C Tag 2019-12-11 lub nowszy Link
Python Wersja 2.0.0 lub nowsza Link
C# Wersja 1.21.4 lub nowsza Link
Java Wersja 1.19.0 lub nowsza Link
NodeJS Wersja 1.12.2 lub nowsza Link

Urządzenia usługi IoT Edge można skonfigurować do używania protokołu TLS 1.2 podczas komunikacji z usługą IoT Hub. W tym celu użyj strony dokumentacji usługi IoT Edge.

Uwierzytelnianie urządzeń

Po pomyślnym uzgadnianiu protokołu TLS usługa IoT Hub może uwierzytelniać urządzenie przy użyciu klucza symetrycznego lub certyfikatu X.509. W przypadku uwierzytelniania opartego na certyfikatach może to być dowolny certyfikat X.509, w tym ECC. Usługa IoT Hub weryfikuje certyfikat względem podanego odcisku palca lub urzędu certyfikacji. Aby dowiedzieć się więcej, zobacz Obsługiwane certyfikaty X.509.

Obsługa wzajemnego protokołu TLS

Wzajemne uwierzytelnianie TLS gwarantuje, że klient uwierzytelnia certyfikat serwera (IoT Hub), a serwer (IoT Hub) uwierzytelniacertyfikat klienta X.509 lub odcisk palca X.509. Autoryzacja jest wykonywana przez usługę IoT Hub po zakończeniu uwierzytelniania .

W przypadku protokołów AMQP i MQTT usługa IoT Hub żąda certyfikatu klienta w początkowym uzgadnianiu protokołu TLS. Jeśli zostanie podany, usługa IoT Hub uwierzytelnia certyfikat klienta, a klient uwierzytelnia certyfikat usługi IoT Hub. Ten proces jest nazywany wzajemnym uwierzytelnianiem TLS. Gdy usługa IoT Hub odbiera pakiet połączenia MQTT lub zostanie otwarty link AMQP, usługa IoT Hub wykonuje autoryzację dla klienta żądającego i określa, czy klient wymaga uwierzytelniania X.509. Jeśli wzajemne uwierzytelnianie TLS zostało ukończone, a klient ma autoryzację do nawiązywania połączenia jako urządzenia, jest dozwolony. Jeśli jednak klient wymaga uwierzytelniania X.509, a uwierzytelnianie klienta nie zostało ukończone podczas uzgadniania protokołu TLS, usługa IoT Hub odrzuca połączenie.

W przypadku protokołu HTTP, gdy klient wysyła pierwsze żądanie, usługa IoT Hub sprawdza, czy klient wymaga uwierzytelniania X.509, a jeśli uwierzytelnianie klienta zostało ukończone, usługa IoT Hub wykonuje autoryzację. Jeśli uwierzytelnianie klienta nie zostało ukończone, usługa IoT Hub odrzuca połączenie

Przypinanie certyfikatu

Przypinanie certyfikatów i filtrowanie certyfikatów serwera TLS (czyli certyfikatów liści) i certyfikatów pośrednich skojarzonych z punktami końcowymi usługi IoT Hub jest zdecydowanie odradzane, ponieważ firma Microsoft często wdraża te certyfikaty z niewielkim wyprzedzeniem lub bez powiadomienia. Jeśli musisz, przypnij tylko certyfikaty główne zgodnie z opisem w tym wpisie w blogu usługi Azure IoT.

Negocjowanie maksymalnej długości fragmentu protokołu TLS (wersja zapoznawcza)

Usługa IoT Hub obsługuje również negocjowanie maksymalnej długości fragmentu protokołu TLS, co jest czasami nazywane negocjowaniem rozmiaru ramki PROTOKOŁU TLS. Ta funkcja jest dostępna w publicznej wersji zapoznawczej.

Ta funkcja umożliwia określenie maksymalnej długości fragmentu zwykłego tekstu do wartości mniejszej niż domyślna 2^14 bajtów. Po wynegocjowaniu usługa IoT Hub i klient zaczynają fragmentować komunikaty, aby upewnić się, że wszystkie fragmenty są mniejsze niż długość wynegocjowanej. To zachowanie jest przydatne w przypadku urządzeń z ograniczonymi obliczeniami lub pamięcią. Aby dowiedzieć się więcej, zobacz oficjalną specyfikację rozszerzenia TLS.

Oficjalna obsługa zestawu SDK dla tej funkcji publicznej wersji zapoznawczej nie jest jeszcze dostępna. Aby rozpocząć pracę

  1. Utwórz nowe centrum IoT z włączonym trybem podglądu.
  2. W przypadku korzystania z biblioteki OpenSSL wywołaj SSL_CTX_set_tlsext_max_fragment_length , aby określić rozmiar fragmentu.
  3. Połączenie klienta do usługi IoT Hub w wersji zapoznawczej.

Następne kroki