Supporto TLS (Transport Layer Security) nell'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 all'hub IoT.

Certificato TLS del server dell'hub IoT

Durante un handshake TLS, l'hub IoT presenta 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 all'hub IoT. Per altre informazioni, vedere Aggiornamentodel 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:

• Radice CA Baltimore CyberTrust
• Radice CA DigiCert Global G2
• Radice CA Microsoft RSA 2017

Per i collegamenti per scaricare questi certificati, vedere Dettagli dell'autorità di certificazione di Azure.

Certificato TLS server ECC (Elliptic Curve Cryptography) (anteprima)

Il certificato TLS del server ECC dell'hub IoT è 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
• Radice CA Microsoft RSA 2017

Per i collegamenti per scaricare questi certificati, vedere Dettagli dell'autorità di certificazione di Azure.

Per visualizzare in anteprima il certificato del server ECC dell'hub IoT:

1. Creare un nuovo hub IoT con la modalità di anteprima attivata.
2. 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_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. Connettere il client all'hub IoT di anteprima.

Imposizione di TLS 1.2 disponibile nelle aree selezionate

Per ulteriore sicurezza, configurare gli hub IoT per consentire soltanto le connessioni client che usano la versione 1.2 di TLS e per applicare l'uso delle crittografie consigliate. Questa funzionalità è supportata solo in queste aree:

• Stati Uniti orientali
• Stati Uniti centro-meridionali
• West US 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 un hub IoT nel portale di Azure, ad eccezione di

• Scegliere un'area da una nell'elenco precedente.

• In Gestione -> Avanzata -> 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 proprietà minTlsVersion 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 nel messaggio ClientHello non è indicata alcuna delle crittografie consigliate.

Pacchetti di crittografia

Gli hub IoT configurati per accettare solo TLS 1.2 imporranno anche l'uso delle suite di crittografia consigliate seguenti:

• 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

Per gli hub IoT non configurati per l'applicazione di tutela TLS 1.2, quest'ultimo funziona comunque con le suite di crittografia seguenti:

• 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(Questa 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 dall'hub IoT (ad esempio, ECDHE-ECDSA-AES256-GCM-SHA384). In questo caso, l'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.

È 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, l'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. L'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 dall'hub IoT al termine dell'autenticazione.

Per i protocolli AMQP e MQTT, l'hub IoT richiede un certificato client nell'handshake TLS iniziale. Se ne viene fornito uno, l'hub IoT autentica il certificato client e il client autentica il certificato dell'hub IoT. Questo processo è detto autenticazione TLS reciproca. Quando l'hub IoT riceve un pacchetto di connessione MQTT o viene aperto un collegamento AMQP, l'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, l'hub IoT rifiuta la connessione.

Per il protocollo HTTP, quando il client effettua la prima richiesta, l'hub IoT verifica se il client richiede l'autenticazione X.509 e se l'autenticazione client è stata completata, l'hub IoT esegue l'autorizzazione. Se l'autenticazione client non è stata completata, l'hub IoT rifiuta la connessione

Aggiunta di certificati

L'aggiunta certificati e il filtro dei del server TLS (noti anche come certificati foglia) e i certificati intermedi associati agli endpoint dell'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)

L'hub IoT supporta anche la negoziazione della lunghezza massima del frammento TLS, talvolta nota come negoziazione delle dimensioni dei frame 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, l'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. Attività iniziali

1. Creare un nuovo hub IoT con la modalità di anteprima attivata.
2. Quando si usa OpenSSL, chiamare SSL_CTX_set_tlsext_max_fragment_length per specificare le dimensioni del frammento.
3. Connettere il client all'hub IoT di anteprima.

Passaggi successivi

• Per altre informazioni sulla sicurezza e il controllo di accesso dell'hub IoT, vedere Controllare l'accesso all'hub IoT.
• Per altre informazioni sull'uso del certificato X509 per l'autenticazione del dispositivo, vedere Autenticazione del dispositivo con certificati CA X.509