Dukungan Keamanan Lapisan Transportasi (TLS) di IoT Hub

IoT Hub menggunakan Keamanan Lapisan Transportasi (TLS) untuk mengamankan koneksi dari perangkat dan layanan IoT. Tiga versi protokol TLS saat ini didukung, yaitu versi 1.0, 1.1, dan 1.2.

TLS 1.0 dan 1.1 dianggap warisan dan direncanakan untuk dihentikan. Untuk informasi selengkapnya, lihat Menghentikan TLS 1.0 dan 1.1 untuk IoT Hub. Untuk menghindari masalah di masa mendatang, gunakan TLS 1.2 sebagai satu-satunya versi TLS saat menyambungkan ke IoT Hub.

Sertifikat TLS server IoT Hub

Selama jabat tangan TLS, IoT Hub menyajikan sertifikat server bertanda RSA untuk menghubungkan klien. Di masa lalu, sertifikat semuanya berakar dari Ca Akar Cybertrust Baltimore. Karena akar Baltimore berada di akhir kehidupan, kami sedang dalam proses migrasi ke akar baru yang disebut DigiCert Global G2. Migrasi ini berdampak pada semua perangkat yang saat ini terhubung ke IoT Hub. Untuk informasi selengkapnya, lihat Pembaruan sertifikat IoT TLS.

Meskipun migrasi CA akar jarang terjadi, untuk ketahanan dalam lanskap keamanan modern, Anda harus menyiapkan skenario IoT Anda untuk kejadian yang tidak mungkin terjadi bahwa CA akar disusupi atau migrasi CA akar darurat diperlukan. Kami sangat menyarankan agar semua perangkat mempercayai tiga CA root berikut:

  • CA akar Baltimore CyberTrust
  • CA akar DigiCert Global G2
  • Microsoft RSA root CA 2017

Untuk tautan untuk mengunduh sertifikat ini, lihat Detail Otoritas Sertifikat Azure.

Sertifikat TLS server Elliptic Curve Cryptography (ECC) (pratinjau)

Sertifikat TLS server ECC IoT Hub tersedia untuk pratinjau publik. Meskipun menawarkan keamanan yang serupa dengan sertifikat RSA, validasi sertifikat ECC (dengan rangkaian sandi khusus ECC) menggunakan komputasi, memori, dan bandwidth hingga 40% lebih sedikit. Penghematan ini penting untuk perangkat IoT karena profil dan memorinya yang lebih kecil, dan untuk mendukung kasus penggunaan di lingkungan bandwidth jaringan yang terbatas.

Kami sangat menyarankan agar semua perangkat yang menggunakan ECC mempercayai dua CA root berikut:

  • CA akar DigiCert Global G3
  • Microsoft RSA root CA 2017

Untuk tautan untuk mengunduh sertifikat ini, lihat Detail Otoritas Sertifikat Azure.

Untuk mempratinjau sertifikat server ECC IoT Hub:

  1. Buat IoT Hub baru dengan mode pratinjau aktif.
  2. Konfigurasikan klien Anda untuk hanya menyertakan rangkaian sandi ECDSA dan mengecualikan yang RSA. Ini adalah cipher suite yang didukung untuk pratinjau publik sertifikat 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. Sambungkan klien Anda ke IoT Hub pratinjau.

Pemberlakuan TLS 1.2 tersedia di wilayah tertentu

Untuk keamanan tambahan, konfigurasikan IoT Hub Anda untuk hanya mengizinkan koneksi klien yang menggunakan TLS versi 1.2 dan untuk memberlakukan penggunaan rangkaian sandi. Fitur ini hanya didukung di wilayah ini:

  • AS Timur
  • US Tengah Selatan
  • US Barat 2
  • US Gov Arizona
  • US Gov Virginia (dukungan TLS 1.0/1.1 tidak tersedia di wilayah ini - Pemberlakuan TLS 1.2 harus diaktifkan atau pembuatan IoT Hub gagal)

Untuk mengaktifkan pemberlakuan TLS 1.2, ikuti langkah-langkah dalam Membuat IoT Hub di portal Microsoft Azure, kecuali

  • Pilih Wilayah dari salah satu daftar di atas.

  • Di bawah Manajemen -> Tingkat Lanjut -> Keamanan Lapisan Transportasi (TLS) -> Versi TLS minimum, pilih 1.2. Pengaturan ini hanya muncul untuk IoT Hub yang dibuat di wilayah yang didukung.

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

Untuk menggunakan templat ARM untuk pembuatan, sediakan IoT Hub baru di salah satu wilayah yang didukung dan atur properti minTlsVersion ke 1.2 dalam spesifikasi sumber daya:

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

Sumber daya IoT Hub yang dibuat menggunakan konfigurasi ini akan menolak klien layanan dan perangkat yang mencoba tersambung menggunakan TLS versi 1.0 dan 1.1. Demikian pula, jabat tangan TLS akan ditolak jika pesan ClientHello tidak mencantumkan salah satu sandi yang disarankan.

Catatan

Properti minTlsVersion merupakan properti baca-saja dan tak dapat diubah setelah sumber daya IoT Hub Anda dibuat. Oleh karena itu, penting bagi Anda untuk menguji dan memvalidasi dengan benar bahwa semua layanan dan perangkat IoT Anda kompatibel dengan TLS 1.2 dan sandi yang disarankan sebelumnya.

Setelah failover, properti minTlsVersion IoT Hub Anda akan tetap efektif di wilayah yang dipasangkan geografis pasca-failover.

Cipher suite

IoT Hub yang dikonfigurasi untuk hanya menerima TLS 1.2 juga akan memberlakukan penggunaan rangkaian sandi yang disarankan berikut:

  • 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

Untuk IoT Hub yang tidak dikonfigurasi untuk pemberlakuan TLS 1.2, TLS 1.2 masih berfungsi dengan rangkaian sandi berikut:

  • 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(Cipher ini tidak akan digunakan lagi pada 10/01/2022 dan tidak akan lagi digunakan untuk jabat tangan TLS)

Klien dapat menyarankan daftar rangkaian sandi yang lebih tinggi untuk digunakan selama ClientHello. Namun, beberapa dari rangkaian sandi tersebut mungkin tidak didukung oleh IoT Hub (misalnya, ECDHE-ECDSA-AES256-GCM-SHA384). Dalam hal ini, IoT Hub akan mencoba mengikuti preferensi klien, tetapi akhirnya bernegosiasi dengan rangkaian sandi dengan ServerHello.

Konfigurasi TLS untuk SDK dan IoT Edge

Gunakan tautan di bawah untuk mengonfigurasi TLS 1.2 dan sandi yang diizinkan di SDK klien IoT Hub.

Bahasa Versi yang mendukung TLS 1.2 Dokumentasi
C Tag 2019-12-11 atau yang lebih baru Tautan
Python Versi 2.0.0 atau yang lebih baru Tautan
C# Versi 1.21.4 atau yang lebih baru Tautan
Java Versi 1.19.0 atau yang lebih baru Tautan
NodeJS Versi 1.12.2 atau yang lebih baru Tautan

Perangkat IoT Edge dapat dikonfigurasi untuk menggunakan TLS 1.2 saat berkomunikasi dengan IoT Hub. Untuk tujuan ini, gunakan halaman dokumentasi IoT Edge.

Autentikasi perangkat

Setelah jabat tangan TLS berhasil, IoT Hub dapat mengautentikasi perangkat menggunakan kunci konten atau sertifikat X.509. Untuk autentikasi berbasis sertifikat, ini dapat berupa sertifikat X.509 apa pun, termasuk ECC. IoT Hub memvalidasi sertifikat terhadap thumbprint atau otoritas sertifikat (OS) yang Anda berikan. Untuk mempelajari selengkapnya, lihat Sertifikat X.509 yang didukung.

Dukungan TLS timbal balik

Autentikasi TLS bersama memastikan bahwa klien mengautentikasi sertifikat server (IoT Hub) dan server (IoT Hub) mengautentikasi sertifikat klien X.509 atau thumbprint X.509. Otorisasi dilakukan oleh IoT Hub setelah autentikasi selesai.

Untuk protokol AMQP dan MQTT, IoT Hub meminta sertifikat klien dalam jabat tangan TLS awal. Jika disediakan, IoT Hub mengautentikasi sertifikat klien dan klien mengautentikasi sertifikat IoT Hub. Proses ini disebut autentikasi TLS bersama. Ketika IoT Hub menerima paket MQTT connect atau tautan AMQP terbuka, IoT Hub melakukan otorisasi untuk klien yang meminta dan menentukan apakah klien memerlukan autentikasi X.509. Jika autentikasi TLS bersama selesai dan klien berwenang untuk terhubung sebagai perangkat, itu diizinkan. Namun, jika klien memerlukan autentikasi X.509 dan autentikasi klien tidak selesai selama jabat tangan TLS, maka IoT Hub menolak koneksi.

Untuk protokol HTTP, ketika klien membuat permintaan pertamanya, IoT Hub memeriksa apakah klien memerlukan autentikasi X.509 dan jika autentikasi klien selesai, maka IoT Hub melakukan otorisasi. Jika autentikasi klien tidak selesai, maka IoT Hub menolak koneksi

Penyematan sertifikat

Penyematan sertifikat dan pemfilteran sertifikat server TLS (alias sertifikat daun) dan sertifikat perantara yang terkait dengan titik akhir IoT Hub sangat tidak dianjurkan karena Microsoft sering kali menggulung sertifikat ini dengan sedikit atau tanpa pemberitahuan. Jika harus dilakukan, sematkan sertifikat akar seperti yang dijelaskan dalam posting blog Azure IoT ini saja.

Negosiasi panjang fragmen maksimum TLS (pratinjau)

IoT Hub juga mendukung negosiasi panjang fragmen maksimum TLS, yang kadang-kadang dikenal sebagai negosiasi ukuran bingkai TLS. Fitur ini berada dalam pratinjau publik.

Gunakan fitur ini untuk menentukan panjang fragmen plaintext maksimum ke nilai yang lebih kecil dari byte 2^14 default. Setelah dinegosiasikan, IoT Hub dan klien mulai memecah pesan untuk memastikan semua fragmen lebih kecil dari panjang yang dinegosiasikan. Perilaku ini sangat membantu untuk perangkat yang dibatasi memori atau komputasi. Untuk mempelajari selengkapnya, lihat spesifikasi ekstensi TLS resmi.

Dukungan SDK resmi untuk fitur pratinjau publik ini belum tersedia. Untuk memulai

  1. Buat IoT Hub baru dengan mode pratinjau aktif.
  2. Saat menggunakan OpenSSL, panggil SSL_CTX_set_tlsext_max_fragment_length untuk menentukan ukuran fragmen.
  3. Sambungkan klien Anda ke IoT Hub pratinjau.

Langkah berikutnya