Compartir a través de

Azure Service Bus: Implementar uso TLS 1.2 (es-MX)

  • Artículo

Credits

Artículo original: https://blogs.msdn.microsoft.com/servicebus/2018/11/22/enforcing-tls-1-2-use-with-azure-service-bus/

Introducción

 El compromiso a largo plazo de admitir protocolos y versiones de protocolos es una expectativa clave que los clientes tienen de los servicios de nube. Se espera que las soluciones implementadas, y especialmente las aplicaciones cliente ampliamente implementadas que, a menudo se operan fuera del control del desarrollador original, no se rompan espontáneamente y se eliminen de los servicios en la nube por los protocolos que se retiran.

Cuando se trata de soporte a largo plazo, los protocolos de seguridad como Transport Layer Security (TLS, coloquialmente también conocidos como SSL) son los más difíciles de administrar, porque los profesionales de la seguridad de la información presionan para actualizar de manera conveniente a las últimas versiones lo antes posible. - con las políticas de seguridad de la información que reflejan esto - aunque hay implementaciones importantes de clientes "por ahí" que no pueden actualizarse fácilmente a la última versión, a menudo también debido a limitaciones de la plataforma. "Simplemente cambie el código al último tiempo de ejecución y recompile" a menudo no es una opción práctica por una variedad de razones.

Azure Service Bus es uno de los servicios más antiguos de Azure, ya que algunos de sus protocolos existentes están actualmente en uso por parte de los clientes, incluso antes de la disponibilidad comercial en 2010, y hay muchas aplicaciones que se han desarrollado y desplegado hace años. utilizando TLS 1.0 y los ISV y / o clientes consideran que "simplemente funcionan". TLS 1.0 es problemático, pero para algunos clientes no es lo suficientemente problemático como para apresurarse a retirar todos sus usos en sistemas más antiguos. Por eso TLS 1.0 y TLS 1.1 continúa como una opción.

Dicho todo esto: si las implementaciones de aplicaciones bajo su control aún dependen de TLS 1.0 o TLS 1.1, esas se encuentran en tiempo contado. El reloj no se detiene y muchos de los clientes que se sabe tienen tales dependencias ya han recibido o recibirán comunicaciones de Azure a tal efecto; La plataforma de Azure retirará TLS 1.0 y TLS 1.1 como una cuestión de política global, todo al mismo tiempo para los servicios que aún lo admiten.

Incluso mientras TLS 1.0 y TLS 1.1 siguen siendo una opción en las puertas de enlace de Azure Service Bus, sus propias aplicaciones pueden garantizar el cumplimiento total de las políticas actuales y utilizar siempre TLS 1.2. La versión del protocolo TLS y las suites de cifrado TLS son, en última instancia, siempre una elección del cliente, y el cliente siempre puede negarse a seguir comunicándose si las capacidades ofrecidas están fuera del marco de cumplimiento deseado.

Forzar el uso de TLS 1.2 con clientes en soporte

Si sus clientes de Bus de servicio están actualizados, generalmente está utilizando TLS 1.2.

Si está utilizando alguna versión del cliente estándar de .NET oficial (Microsoft.Azure.ServiceBus en Nuget) o la versión 3.4.3 o posterior del cliente de .NET Framework (WindowsAzure.ServiceBus en Nuget) y está utilizando .NET Framework 4.7.1 o más reciente, su aplicación seguirá automáticamente el modelo de guía de .NET Framework para TLS y siempre seguirá las configuraciones de configuración del sistema operativo y las anulaciones respectivas de .NET Framework. Las versiones actuales de Windows por defecto utilizan TLS 1.2.

Para .NET Framework 4.6, tendrá que imponer el uso de TLS 1.2 en el inicio de su aplicación configurando

ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12

o mediante la aplicación del uso de túneles HTTPS (ver más abajo).

Si está utilizando el cliente oficial de Java (azure-servicebus en Maven), el cliente seguirá automáticamente las reglas de la plataforma Java para aplicar TLS 1.2, donde TLS 1.2 es el valor predeterminado.

Si está utilizando un cliente AMQP 1.0 personalizado, consulte la documentación del proyecto correspondiente para saber cómo hacer cumplir el uso de TLS 1.2. Las bibliotecas AMQP de nivel inferior de Microsoft para .NET (Microsoft.Azure.Amqp y AmqpNetLite) siguen la guía de .NET Framework y se establecen de forma predeterminada en TLS 1.2. Las bibliotecas AMQP de Apache Qpid Proton generalmente tienen el valor predeterminado de TLS 1.2 en la actualidad.

Forzar el uso de TLS 1.2 con clientes fuera de soporte

Los únicos escenarios en los que imponer el uso de TLS 1.2 son sustancialmente más complicados incluyen el uso de clientes desactualizados en los que es imposible seguir la guía de .NET Framework para actualizar a .NET 4.7.2.

Si está utilizando el cliente de .NET Framework (WindowsAzure.ServiceBus en Nuget) con la versión 4.5.x de .NET Framework y está utilizando el transporte AMQP, debe usar la versión 3.4.3 de ese cliente o posterior para imponer el uso de TLS 1.2.

Si, en cambio, está utilizando el transporte NetMessaging (predeterminado), que se basa en WCF, las versiones 4.5.x de .NET Framework y anteriores tienen la versión 1.0 de TLS codificada para la opción de transporte nativa de WCF, pero para Service Bus puede evitar esto cuando impone la tunelización HTTPS, que sigue las reglas predeterminadas del sistema operativo.

Si no tiene acceso al código fuente o no puede cambiar su implementación, y el cliente no reemplaza explícitamente la configuración de ServiceBusEnvironment.SystemConnectivity.Mode a ConnectivityMode.Tcp, simplemente puede imponer el uso del túnel HTTPS suprimiendo la conectividad de salida en los puertos 9350 -9354 con un firewall local.

Puede imponer el uso de HTTPS configurando

ServiceBusEnvironment.SystemConnectivity.Mode=ConnectivityMode.Https

Suites de cifrado soportadas

Una preocupación clave con las implementaciones más antiguas de TLS es que prefieren las suites de cifrado desactualizadas. La configuración de Service Bus TLS solo ofrece las siguientes opciones, en orden de preferencia del lado del servicio.

Las últimas tres opciones solo se retienen temporalmente por compatibilidad con algunos de los clientes más antiguos.

  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027), ECDH x25519 (eq. 3072 bits RSA) 
  • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014), ECDH x25519 (eq. 3072 bits RSA)  
  • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013), ECDH x25519 (eq. 3072 bits RSA)
  • TLS_RSA_WITH_AES_256_GCM_SHA384 (0x9d)  
  • TLS_RSA_WITH_AES_128_GCM_SHA256 (0x9c)  
  • TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d)  
  • TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c)  
  • TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 
  • TLS_RSA_WITH_AES_128_CBC_SHA (0x2f)  
  • TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 

Concluyendo

Verifique que sus aplicaciones estén configuradas para usar TLS 1.2. Si lo hacen, y esto es puramente una elección del cliente, sus aplicaciones cumplirán con todas las políticas que requieren TLS 1.2.

Si bien TLS 1.0 y TLS 1.1 siguen siendo una opción de punto final en Service Bus, debe considerar urgente mover las aplicaciones existentes que usan clientes sin soporte a TLS 1.2, ya que es previsible que estas versiones se retiren del uso en toda la nube de Azure. servicios.