Suporte a Transport Layer Security (TLS) no Hub IoT
O Hub IoT usa TLS (Transport Layer Security) para proteger conexões de dispositivos e serviços IoT. Três versões do protocolo TLS são suportadas atualmente, ou seja, as versões 1.0, 1.1 e 1.2.
TLS 1.0 e 1.1 são considerados legados e estão planejados para descontinuação. Para obter mais informações, consulte Substituindo o TLS 1.0 e 1.1 para o Hub IoT. Para evitar problemas futuros, use o TLS 1.2 como a única versão do TLS ao se conectar ao Hub IoT.
Certificado TLS do servidor do Hub IoT
Durante um handshake TLS, o Hub IoT apresenta certificados de servidor com chave RSA para conectar clientes. No passado, os certificados eram todos enraizados a partir da CA raiz do Baltimore Cybertrust. Como a raiz de Baltimore está em fim de vida, estamos no processo de migração para uma nova raiz chamada DigiCert Global G2. Essa migração afeta todos os dispositivos atualmente conectados ao Hub IoT. Para obter mais informações, consulte Atualização do certificado TLS da IoT.
Embora as migrações de autoridade de certificação raiz sejam raras, para resiliência no cenário de segurança moderno, você deve preparar seu cenário de IoT para o evento improvável de que uma autoridade de certificação raiz seja comprometida ou uma migração de autoridade de certificação raiz de emergência seja necessária. É altamente recomendável que todos os dispositivos confiem nas três CAs raiz a seguir:
- AC raiz do Baltimore CyberTrust
- DigiCert Global G2 raiz CA
- Raiz do Microsoft RSA CA 2017
Para obter links para baixar esses certificados, consulte Detalhes da Autoridade de Certificação do Azure.
Certificado TLS do servidor ECC (Elliptic Curve Cryptography) (visualização)
O certificado TLS do servidor ECC do Hub IoT está disponível para visualização pública. Embora ofereça segurança semelhante aos certificados RSA, a validação de certificados ECC (com pacotes de codificação somente ECC) usa até 40% menos computação, memória e largura de banda. Essas economias são importantes para dispositivos IoT por causa de seus perfis e memória menores, e para suportar casos de uso em ambientes de largura de banda de rede limitados.
É altamente recomendável que todos os dispositivos que usam ECC confiem nas duas CAs raiz a seguir:
- DigiCert Global G3 raiz CA
- Raiz do Microsoft RSA CA 2017
Para obter links para baixar esses certificados, consulte Detalhes da Autoridade de Certificação do Azure.
Para visualizar o certificado do servidor ECC do Hub IoT:
- Crie um novo hub IoT com o modo de visualização ativado.
- Configure seu cliente para incluir apenas pacotes de codificação ECDSA e excluir quaisquer pacotes RSA . Estes são os pacotes de codificação suportados para a visualização pública do certificado 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
- Conecte seu cliente ao hub IoT de visualização.
Aplicação do TLS 1.2 disponível em regiões selecionadas
Para maior segurança, configure seus Hubs IoT para permitir apenas conexões de cliente que usam TLS versão 1.2 e para impor o uso de pacotes de codificação. Este recurso só é suportado nestas regiões:
- E.U.A. Leste
- E.U.A. Centro-Sul
- E.U.A. Oeste 2
- US Gov - Arizona
- US Gov Virginia (o suporte a TLS 1.0/1.1 não está disponível nesta região - a imposição do TLS 1.2 deve estar habilitada ou a criação do hub IoT falha)
Para habilitar a imposição do TLS 1.2, siga as etapas em Criar hub IoT no portal do Azure, exceto
Escolha uma região de uma na lista acima.
Em Gerenciamento - Avançado - Transport Layer Security (TLS) ->>> Versão mínima do TLS, selecione 1.2. Essa configuração só aparece para o hub IoT criado na região suportada.
Para usar o modelo ARM para criação, provisione um novo Hub IoT em qualquer uma das regiões suportadas e defina a minTlsVersion propriedade como 1.2 na especificação do recurso:
{
"$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
}
}
]
}
O recurso do Hub IoT criado usando essa configuração recusará clientes de dispositivo e serviço que tentarem se conectar usando as versões 1.0 e 1.1 do TLS. Da mesma forma, o handshake TLS será recusado se a ClientHello mensagem não listar nenhuma das cifras recomendadas.
Nota
A minTlsVersion propriedade é somente leitura e não pode ser alterada depois que o recurso do Hub IoT for criado. Portanto, é essencial que você teste e valide adequadamente se todos os seus dispositivos e serviços IoT são compatíveis com TLS 1.2 e as cifras recomendadas com antecedência.
Após failovers, a minTlsVersion propriedade do seu Hub IoT permanecerá efetiva na região pós-failover emparelhada geograficamente.
Conjuntos de cifras
Os Hubs IoT configurados para aceitar apenas TLS 1.2 também imporão o uso dos seguintes pacotes de codificação recomendados:
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
Para Hubs IoT não configurados para imposição de TLS 1.2, o TLS 1.2 ainda funciona com os seguintes pacotes de criptografia:
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_SHA(Esta cifra será preterida em 10/01/2022 e não será mais usada para apertos de mão TLS)
Um cliente pode sugerir uma lista de pacotes de codificação mais altos para usar durante ClientHelloo . No entanto, alguns deles podem não ser suportados pelo Hub IoT (por exemplo, ECDHE-ECDSA-AES256-GCM-SHA384). Neste caso, o Hub IoT tentará seguir a preferência do cliente, mas eventualmente negociará o pacote de codificação com ServerHelloa .
Configuração TLS para SDK e IoT Edge
Use os links abaixo para configurar o TLS 1.2 e as cifras permitidas em SDKs de cliente do Hub IoT.
| Idioma | Versões que suportam TLS 1.2 | Documentação |
|---|---|---|
| C | Tag 2019-12-11 ou mais recente | Ligação |
| Python | Versão 2.0.0 ou mais recente | Ligação |
| C# | Versão 1.21.4 ou mais recente | Ligação |
| Java | Versão 1.19.0 ou mais recente | Ligação |
| NodeJS | Versão 1.12.2 ou mais recente | Ligação |
Os dispositivos IoT Edge podem ser configurados para usar TLS 1.2 ao se comunicar com o Hub IoT. Para isso, use a página de documentação do IoT Edge.
Autenticação do dispositivo
Após um handshake TLS bem-sucedido, o Hub IoT pode autenticar um dispositivo usando uma chave simétrica ou um certificado X.509. Para autenticação baseada em certificado, pode ser qualquer certificado X.509, incluindo ECC. O Hub IoT valida o certificado em relação à impressão digital ou à autoridade de certificação (CA) fornecida. Para saber mais, consulte Certificados X.509 suportados.
Suporte TLS mútuo
A autenticação TLS mútua garante que o cliente autentique o certificado do servidor (Hub IoT) e o servidor (Hub IoT) autentique o certificado do cliente X.509 ou a impressão digital X.509. A autorização é executada pelo Hub IoT após a conclusão da autenticação .
Para protocolos AMQP e MQTT, o Hub IoT solicita um certificado de cliente no handshake TLS inicial. Se for fornecido, o Hub IoT autentica o certificado do cliente e o cliente autentica o certificado do Hub IoT. Esse processo é chamado de autenticação TLS mútua. Quando o Hub IoT recebe um pacote de conexão MQTT ou um link AMQP é aberto, o Hub IoT executa a autorização para o cliente solicitante e determina se o cliente requer autenticação X.509. Se a autenticação TLS mútua foi concluída e o cliente está autorizado a se conectar como o dispositivo, ela é permitida. No entanto, se o cliente exigir autenticação X.509 e a autenticação do cliente não tiver sido concluída durante o handshake TLS, o Hub IoT rejeitará a conexão.
Para o protocolo HTTP, quando o cliente faz sua primeira solicitação, o Hub IoT verifica se o cliente requer autenticação X.509 e se a autenticação do cliente foi concluída, o Hub IoT executa a autorização. Se a autenticação do cliente não estiver concluída, o Hub IoT rejeitará a conexão
Fixação do certificado
A fixação e filtragem de certificados do servidor TLS (também conhecidos como certificados folha) e certificados intermediários associados aos pontos de extremidade do Hub IoT é fortemente desencorajada, pois a Microsoft frequentemente rola esses certificados com pouco ou nenhum aviso. Se necessário, fixe apenas os certificados raiz conforme descrito nesta postagem do blog do Azure IoT.
Negociação de comprimento máximo de fragmento TLS (visualização)
O Hub IoT também oferece suporte à negociação de comprimento máximo de fragmento TLS, que às vezes é conhecida como negociação de tamanho de quadro TLS. Esta funcionalidade está em pré-visualização pública.
Use esse recurso para especificar o comprimento máximo do fragmento de texto sem formatação para um valor menor do que os 2^14 bytes padrão. Uma vez negociado, o Hub IoT e o cliente começam a fragmentar as mensagens para garantir que todos os fragmentos sejam menores do que o comprimento negociado. Esse comportamento é útil para dispositivos com restrição de memória ou computação. Para saber mais, consulte as especificações oficiais da extensão TLS.
O suporte oficial do SDK para este recurso de visualização pública ainda não está disponível. Para começar
- Crie um novo hub IoT com o modo de visualização ativado.
- Ao usar OpenSSL, chame SSL_CTX_set_tlsext_max_fragment_length para especificar o tamanho do fragmento.
- Conecte seu cliente à visualização do Hub IoT.
Próximos passos
- Para saber mais sobre segurança e controle de acesso do Hub IoT, consulte Controlar o acesso ao Hub IoT.
- Para saber mais sobre como usar o certificado X509 para autenticação de dispositivo, consulte Autenticação de dispositivo usando certificados de autoridade de certificação X.509