Supporto tls (Transport Layer Security) in hub IoT
L'hub IoT usa il protocollo Transport Layer Security (TLS) per la protezione delle connessioni dai dispositivi e dai servizi IoT. Attualmente sono supportate tre versioni del protocollo TLS, ovvero le versioni 1.0, 1.1 e 1.2.
Le versioni 1.0 e 1.1 di TLS sono considerate legacy e ne è prevista la deprecazione. Per altre informazioni, vedere Deprecazione di TLS 1.0 e 1.1 nell'hub IoT. Per evitare problemi futuri, usare TLS 1.2 come unica versione TLS durante la connessione a hub IoT.
Certificato TLS del server hub IoT
Durante un handshake TLS, hub IoT presenta i certificati server con chiave RSA per la connessione dei client. In passato, i certificati erano tutti radicati dalla CA Baltimore Cybertrust Root. Poiché la radice baltimora è alla fine della vita, stiamo eseguendo la migrazione a una nuova radice denominata DigiCert Global G2. Questa migrazione influisce su tutti i dispositivi attualmente connessi a hub IoT. Per altre informazioni, vedere Aggiornamento del certificato TLS IoT.
Anche se le migrazioni ca radice sono rare, per la resilienza nel panorama di sicurezza moderno è necessario preparare lo scenario IoT per l'improbabile evento in cui una CA radice è compromessa o è necessaria una migrazione ca radice di emergenza. È consigliabile che tutti i dispositivi considerino attendibili i tre ca radice seguenti:
- Baltimore CyberTrust root CA
- Ca radice DigiCert Global G2
- Microsoft RSA root CA 2017
Per i collegamenti per scaricare questi certificati, vedere Dettagli dell'autorità di certificazione di Azure.
Certificato TLS server ECC (Elliptic Curve Cryptography) (anteprima)
hub IoT certificato TLS del server ECC è disponibile per l'anteprima pubblica. Pur offrendo una sicurezza simile ai certificati RSA, la convalida dei certificati ECC (con pacchetti di crittografia solo ECC) usa fino al 40% meno calcolo, memoria e larghezza di banda. Questi risparmi sono importanti per i dispositivi IoT grazie ai profili e alla memoria più piccoli e supportano i casi d'uso in ambienti con larghezza di banda di rete limitata.
È consigliabile che tutti i dispositivi che usano ECC considerino attendibili i due ca radice seguenti:
- Ca radice DigiCert Global G3
- Microsoft RSA root CA 2017
Per i collegamenti per scaricare questi certificati, vedere Dettagli dell'autorità di certificazione di Azure.
Per visualizzare in anteprima il certificato server ECC di hub IoT:
- Creare un nuovo hub IoT con la modalità di anteprima attivata.
- Configurare il client in modo che includa solo pacchetti di crittografia ECDSA ed escludere quelli RSA. Questi sono i pacchetti di crittografia supportati per l'anteprima pubblica del certificato ECC:
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
- Connessione il client all'hub IoT di anteprima.
Imposizione di TLS 1.2 disponibile nelle aree selezionate
Per una maggiore sicurezza, configurare le hub IoT in modo da consentire solo le connessioni client che usano TLS versione 1.2 e per applicare l'uso di pacchetti di crittografia. Questa funzionalità è supportata solo in queste aree:
- Stati Uniti orientali
- Stati Uniti centro-meridionali
- Stati Uniti occidentali 2
- US Gov Arizona
- US Gov Virginia (il supporto tls 1.0/1.1 non è disponibile in questa area: l'imposizione di TLS 1.2 deve essere abilitata o la creazione dell'hub IoT non riesce)
Per abilitare l'imposizione di TLS 1.2, seguire la procedura descritta in Creare l'hub IoT in portale di Azure, ad eccezione di
Scegliere un'area da una nell'elenco precedente.
In Gestione -> Advanced -> Transport Layer Security (TLS) -> Versione minima di TLS selezionare 1.2. Questa impostazione viene visualizzata solo per l'hub IoT creato nell'area supportata.
Per usare il modello di Resource Manager per la creazione, effettuare il provisioning di un nuovo hub IoT in una delle aree supportate e impostare la minTlsVersion proprietà su 1.2 nella specifica della risorsa:
{
"$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
}
}
]
}
La risorsa dell'hub IoT creata con questa configurazione rifiuterà i client dei dispositivi e dei servizi che tentano di connettersi usando le versioni 1.0 e 1.1 di TLS. Analogamente, l'handshake TLS verrà rifiutato se il ClientHello messaggio non elenca alcuna delle crittografie consigliate.
Nota
La proprietà minTlsVersion è di sola lettura e non è possibile modificarla in seguito alla creazione della risorsa dell'hub IoT. È pertanto essenziale testare e convalidare anticipatamente e in modo adeguato la compatibilità di tutti i dispositivi e i servizi IoT con TLS 1.2 e con le crittografie consigliate.
Al momento del failover, la proprietà minTlsVersion dell'hub IoT rimarrà valida nell'area abbinata in seguito al failover.
Pacchetti di crittografia
hub IoT configurati per accettare solo TLS 1.2 applicano anche l'uso delle seguenti suite di crittografia consigliate:
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
Per le hub IoT non configurate per l'imposizione di TLS 1.2, TLS 1.2 funziona ancora con i pacchetti di crittografia seguenti:
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256TLS_DHE_RSA_WITH_AES_256_GCM_SHA384TLS_DHE_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_GCM_SHA384TLS_RSA_WITH_AES_128_GCM_SHA256TLS_RSA_WITH_AES_256_CBC_SHA256TLS_RSA_WITH_AES_128_CBC_SHA256TLS_ECDHE_RSA_WITH_AES_256_CBC_SHATLS_ECDHE_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_AES_256_CBC_SHATLS_RSA_WITH_AES_128_CBC_SHATLS_RSA_WITH_3DES_EDE_CBC_SHAQuesta crittografia verrà deprecata il 10/01/2022 e non verrà più usata per gli handshake TLS.
Un client può suggerire un elenco di pacchetti di crittografia superiori da usare durante ClientHello. Tuttavia, alcuni di essi potrebbero non essere supportati da hub IoT (ad esempio, ECDHE-ECDSA-AES256-GCM-SHA384). In questo caso, hub IoT tenterà di seguire la preferenza del client, ma alla fine negozierà la suite di crittografia con ServerHello.
Configurazione TLS per SDK e IoT Edge
Usare i collegamenti seguenti per configurare TLS 1.2 e le crittografie consentite negli SDK del client dell'hub IoT.
| Lingua | Versioni che supportano TLS 1.2 | Documentazione |
|---|---|---|
| A | Tag 2019-12-11 o versioni successive | Collegamento |
| Python | Versione 2.0.0 o successive | Collegamento |
| C# | Versione 1.21.4 o successive | Collegamento |
| Java | Versione 1.19.0 o successive | Collegamento |
| NodeJS | Versione 1.12.2 o successive | Collegamento |
È possibile configurare l'uso di TLS 1.2 da parte dei dispositivi IoT Edge durante la comunicazione con l'hub IoT. A tale scopo, vedere la pagina della documentazione di IoT Edge.
Autenticazione del dispositivo
Dopo un handshake TLS riuscito, hub IoT può autenticare un dispositivo usando una chiave simmetrica o un certificato X.509. Per l'autenticazione basata su certificato, questo può essere qualsiasi certificato X.509, incluso ECC. hub IoT convalida il certificato rispetto all'identificazione personale o all'autorità di certificazione (CA) specificata. Per altre informazioni, vedere Certificati X.509 supportati.
Supporto tls reciproco
L'autenticazione TLS reciproca garantisce che il client autentica il certificato del server (hub IoT) e il server (hub IoT) autentica il certificato client X.509 o l'identificazione personale X.509. L'autorizzazione viene eseguita da hub IoT al termine dell'autenticazione.
Per i protocolli AMQP e MQTT, hub IoT richiede un certificato client nell'handshake TLS iniziale. Se ne viene specificato uno, hub IoT autentica il certificato client e il client autentica il certificato hub IoT. Questo processo è detto autenticazione TLS reciproca. Quando hub IoT riceve un pacchetto di connessione MQTT o viene aperto un collegamento AMQP, hub IoT esegue l'autorizzazione per il client richiedente e determina se il client richiede l'autenticazione X.509. Se l'autenticazione TLS reciproca è stata completata e il client è autorizzato a connettersi come dispositivo, è consentito. Tuttavia, se il client richiede l'autenticazione X.509 e l'autenticazione client non è stata completata durante l'handshake TLS, hub IoT rifiuta la connessione.
Per il protocollo HTTP, quando il client effettua la prima richiesta, hub IoT verifica se il client richiede l'autenticazione X.509 e se l'autenticazione client è stata completata, hub IoT esegue l'autorizzazione. Se l'autenticazione client non è stata completata, hub IoT rifiuta la connessione
Aggiunta di certificati
L'aggiunta e il filtro dei certificati server TLS (noti anche come certificati foglia) e i certificati intermedi associati agli endpoint hub IoT sono fortemente sconsigliati perché Microsoft esegue spesso il rollback di questi certificati senza preavviso. Se necessario, aggiungere solo i certificati radice come descritto in questo post di blog di Azure IoT.
Negoziazione della lunghezza massima del frammento TLS (anteprima)
hub IoT supporta anche la negoziazione della lunghezza massima del frammento TLS, talvolta nota come negoziazione delle dimensioni dei fotogrammi TLS. Questa funzionalità è disponibile in anteprima pubblica.
Utilizzare questa funzionalità per specificare la lunghezza massima del frammento di testo non crittografato su un valore inferiore al valore predefinito di 2^14 byte. Dopo la negoziazione, hub IoT e il client iniziano a frammentare i messaggi per garantire che tutti i frammenti siano inferiori alla lunghezza negoziata. Questo comportamento è utile per calcolare o limitare la memoria dei dispositivi. Per altre informazioni, vedere la specifica ufficiale dell'estensione TLS.
Il supporto ufficiale dell'SDK per questa funzionalità di anteprima pubblica non è ancora disponibile. Per iniziare
- Creare un nuovo hub IoT con la modalità di anteprima attivata.
- Quando si usa OpenSSL, chiamare SSL_CTX_set_tlsext_max_fragment_length per specificare le dimensioni del frammento.
- Connessione il client al hub IoT di anteprima.
Passaggi successivi
- Per altre informazioni su hub IoT controllo di sicurezza e accesso, vedere Controllare l'accesso alle hub IoT.
- Per altre informazioni sull'uso del certificato X509 per l'autenticazione del dispositivo, vedere Autenticazione del dispositivo con certificati CA X.509