Compatibilidad de la Seguridad de la capa de transporte (TLS) con IoT Hub
IoT Hub usa Seguridad de la capa de transporte (TLS) para proteger las conexiones de los dispositivos y servicios de IoT. Actualmente se admiten tres versiones del protocolo TLS: 1.0, 1.1 y 1.2.
TLS 1.0 y 1.1 se consideran versiones heredadas y está previsto que dejen de usarse próximamente. Para obtener más información, vea Desuso de TLS 1.0 y 1.1 en IoT Hub. Para evitar problemas en el futuro, use TLS 1.2 como la única versión de TLS al conectarse a IoT Hub.
Certificado TLS para el servidor de IoT Hub
Durante un protocolo de enlace TLS, IoT Hub presenta certificados de servidor con claves RSA para la conexión de clientes. Todos los centros de IoT de la nube global de Azure usan el certificado TLS que emite DigiCert Global Root G2.
También se recomienda agregar certificados de la entidad de certificación raíz de Microsoft RSA 2017 a los dispositivos para evitar interrupciones en caso de que DigiCert Global Root G2 se retire inesperadamente. Aunque las migraciones de entidad de certificación raíz son poco frecuentes, para conseguir resistencia en el panorama de seguridad moderno debe preparar su escenario de IoT para el improbable caso de que una entidad de certificación raíz se vea en peligro o sea necesaria una migración de emergencia.
Se recomienda encarecidamente que todos los dispositivos confíen en las entidades de certificación raíz siguientes:
- DigiCert Global G2
- Microsoft RSA 2017
Para obtener los vínculos para descargar todos estos certificados, consulte los detalles de la entidad de certificación de Azure.
Confianza de certificados en los SDK
Los SDK de dispositivo de Azure IoT conectan y autentican dispositivos a los servicios de Azure IoT. Los distintos SDK administran certificados de diferentes maneras en función del idioma y la versión, pero la mayoría se basan en el almacén de certificados de confianza del dispositivo en lugar de anclar certificados directamente en el código base. Este enfoque proporciona flexibilidad y resistencia para controlar los cambios futuros en los certificados raíz.
En la tabla siguiente se resumen las versiones del SDK que admiten el almacén de certificados de confianza:
| SDK de dispositivos IoT de Azure | Versiones compatibles |
|---|---|
| C | Todas las versiones admitidas actualmente |
| C# | Todas las versiones admitidas actualmente |
| Java | Versión 2.x.x y posteriores |
| Node.js | Todas las versiones admitidas actualmente |
| Python | Todas las versiones admitidas actualmente |
Asignación de certificados
La asignación de certificados y el filtrado de los certificados de servidor TLS (también conocidos como certificados hoja) y los certificados intermedios asociados a puntos de conexión de IoT Hub se desaconseja, ya que Microsoft suele implementar estos certificados con poca o ninguna notificación. Si es necesario, solo ancle los certificados raíz.
Certificado TLS del servidor de criptografía de curva elíptica (ECC) (versión preliminar)
El certificado TLS del servidor de ECC de IoT Hub está disponible para la versión preliminar pública. Aunque ofrece una seguridad similar a los certificados RSA, la validación de certificados ECC (con conjuntos de cifrado solo mediante ECC) usa hasta un 40 % menos de proceso, memoria y ancho de banda. Estos ahorros son importantes para los dispositivos IoT debido a sus perfiles y memoria más pequeños, así como para admitir casos de uso en entornos con un ancho de banda de red limitado.
Se recomienda encarecidamente que todos los dispositivos que usan ECC confíen en las dos entidades de certificación raíz siguientes:
- DigiCert Global G3
- Microsoft RSA 2017
Para obtener los vínculos para descargar todos estos certificados, consulte los detalles de la entidad de certificación de Azure.
Para obtener una vista previa del certificado de servidor de ECC de IoT Hub:
- Cree un centro de IoT con el modo de vista previa activado.
- Configure el cliente para incluir solo conjuntos de cifrado ECDSA y excluir cualquier RSA. Estos son los conjuntos de cifrado compatibles con la versión preliminar pública del 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 el cliente a la vista previa del centro de IoT.
Aplicación TLS 1.2 disponible en regiones seleccionadas
Para mayor seguridad, configure IoT Hub para que solo permita conexiones de clientes que usen la versión 1.2 de TLS y para que exija el uso de conjuntos de cifrado. Esta característica solo se admite en estas regiones:
- Este de EE. UU.
- Centro-sur de EE. UU.
- Oeste de EE. UU. 2
- US Gov: Arizona
- US Gov Virginia (la compatibilidad con TLS 1.0/1.1 no está disponible en esta región: la aplicación TLS 1.2 debe estar habilitada o se producirá un error en la creación de un centro de IoT)
Para habilitar la aplicación de TLS 1.2, siga los pasos descritos en Creación de una instancia de IoT Hub mediante Azure Portal, con la siguiente variación
Elija una Región de entre la lista anterior.
En Administración -> Avanzado -> Seguridad de capa de transporte (TLS) -> Versión de TLS mínima, seleccione 1.2. Esta configuración solo aparece para los centros de IoT creados en la región admitida.
Para usar una plantilla de ARM para la creación, aprovisione una nueva instancia de IoT Hub en cualquiera de las regiones admitidas y establezca la propiedad minTlsVersion en 1.2 en la especificación de recursos:
{
"$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
}
}
]
}
El recurso de IoT Hub creado con esta configuración rechaza los clientes de servicios y dispositivos que intenten conectarse mediante las versiones 1.0 y 1.1 de TLS. Del mismo modo, se rechaza el protocolo de enlace TLS si el mensaje ClientHello no incluye ninguno de los cifrados recomendados.
Nota:
La propiedad minTlsVersion es de solo lectura y no se puede cambiar una vez creado el recurso de IoT Hub. Por lo tanto, es esencial que compruebe y valide de antemano que todos los dispositivos y servicios de IoT son compatibles con TLS 1.2 y con los cifrados recomendados.
En caso de conmutaciones por error, la propiedad minTlsVersion de su IoT Hub seguirá siendo efectiva en la región con emparejamiento geográfico.
Conjuntos de cifrado
Los recursos de IoT Hub que están configurados para aceptar solo TLS 1.2 también exigen el uso de estos conjuntos de cifrado 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
En el caso de los recursos de IoT Hub que no están configurados para exigir TLS 1.2, este protocolo seguirá funcionando con los siguientes conjuntos de cifrado:
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(Este cifrado se pondrá en desuso el 10/01/2022 y ya no se usará para protocolos de enlace TLS)
Un cliente puede sugerir una lista de conjuntos de cifrado mayores para usar durante el mensaje ClientHello. Sin embargo, es posible que no se admitan algunos de los recursos de IoT Hub (por ejemplo, ECDHE-ECDSA-AES256-GCM-SHA384). En este caso, IoT Hub intenta seguir las preferencias del cliente, pero finalmente negociará el conjunto de cifrado con ServerHello.
Configuración de TLS para SDK y IoT Edge
Use los siguientes vínculos para configurar TLS 1.2 y los cifrados permitidos en los SDK de cliente de IoT Hub.
| Lenguaje | Versiones compatibles con TLS 1.2 | Documentación |
|---|---|---|
| C | Etiqueta 2019-12-11 o más reciente | Vínculo |
| Python | Versión 2.0.0 o más reciente | Vínculo |
| C# | Versión 1.21.4 o más reciente | Vínculo |
| Java | Versión 1.19.0 o más reciente | Vínculo |
| NodeJS | Versión 1.12.2 o más reciente | Vínculo |
Los dispositivos de IoT Edge se pueden configurar para que usen TLS 1.2 al comunicarse con IoT Hub. Para más información sobre cómo hacerlo, vea la página de documentación de IoT Edge.
Autenticación de dispositivos
Después de un protocolo de enlace de TLS correcto, IoT Hub puede autenticar un dispositivo mediante una clave simétrica o un certificado X.509. En el caso de la autenticación basada en certificados, puede tratarse de cualquier certificado X.509, incluido ECC. IoT Hub valida el certificado con la huella digital o la entidad de certificación (CA) que proporcione. Para obtener más información, consulte Certificados X.509 compatibles.
Compatibilidad mutua con TLS
La autenticación TLS mutua garantiza que el cliente autentica el certificado de servidor (IoT Hub) y el servidor (IoT Hub) autentica el certificado de cliente X.509 o la huella digital X.509. La autorización se realiza mediante IoT Hub una vez completada la autenticación.
Para los protocolos AMQP y MQTT, IoT Hub solicita un certificado de cliente en el protocolo de enlace TLS inicial. Si se proporciona uno, IoT Hub autentica el certificado de cliente y el cliente autentica el certificado de IoT Hub. Este proceso se denomina autenticación TLS mutua. Cuando IoT Hub recibe un paquete de conexión MQTT o se abre un vínculo AMQP, IoT Hub realiza la autorización del cliente solicitante y determina si el cliente requiere autenticación X.509. Si se completó la autenticación TLS mutua y el cliente está autorizado para conectarse como dispositivo, se le permitirá. Sin embargo, si el cliente requiere la autenticación X.509 y la autenticación del cliente no se completó durante el protocolo de enlace TLS, IoT Hub rechazará la conexión.
En el caso del protocolo HTTP, cuando el cliente realiza su primera solicitud, IoT Hub comprueba si el cliente requiere autenticación X.509 y si se completó la autenticación del cliente, IoT Hub realiza la autorización. Si no se completó la autenticación del cliente, IoT Hub rechaza la conexión.
Negociación de longitud de fragmento máxima de TLS (versión preliminar)
IoT Hub también admite la negociación de longitud de fragmento máxima de TLS, que a veces se conoce como negociación de tamaño del marco de TLS. Esta característica está en versión preliminar pública.
Use esta característica para especificar la longitud máxima del fragmento de texto sin formato en un valor menor que el predeterminado de 2^14 bytes. Una vez realizada la negociación, IoT Hub y el cliente inician la fragmentación de los mensajes para asegurarse de que todos los fragmentos son menores que la longitud negociada. Este comportamiento es útil para los dispositivos que tienen restricciones de proceso o memoria. Para más información, vea la especificación de la extensión TLS oficial.
Todavía no está disponible la compatibilidad del SDK oficial con esta característica en versión preliminar pública. Inicio
- Cree un centro de IoT con el modo de vista previa activado.
- Al usar OpenSSL, llame a SSL_CTX_set_tlsext_max_fragment_length para especificar el tamaño del fragmento.
- Conecte el cliente a la vista previa del centro de IoT.
Pasos siguientes
- Para más información sobre el control de acceso y la seguridad de IoT Hub, vea Control del acceso a IoT Hub.
- Para más información sobre el uso del certificado X.509 para la autenticación de dispositivos, vea Autenticación de dispositivos mediante certificados de entidades de certificación X.509.