Compartir a través de

Solución del problema de TLS 1.0, segunda edición

En este documento se presentan las instrucciones más recientes sobre la identificación y eliminación rápida de las dependencias del protocolo de seguridad de la capa de transporte (TLS) de la versión 1.0 del software basado en sistemas operativos de Microsoft, siguiendo con detalles sobre los cambios de producto y las nuevas características que ofrece Microsoft para proteger sus propios clientes y servicios en línea. Está pensado para usarse como punto de partida para crear un plan de migración a un entorno de red TLS 1.2+. Aunque las soluciones que se describen aquí pueden llevar a cabo y ayudar a quitar el uso de TLS 1.0 en sistemas operativos o bibliotecas criptográficas que no son de Microsoft, no son un foco de este documento.

TLS 1.0 es un protocolo de seguridad definido primero en 1999 para establecer canales de cifrado a través de redes informáticas. Microsoft ha admitido este protocolo desde Windows XP/Server 2003. Aunque ya no se admite el protocolo de seguridad predeterminado en uso por parte de los sistemas operativos modernos, TLS 1.0 sigue siendo compatible con versiones anteriores. La evolución de los requisitos normativos y las nuevas vulnerabilidades de seguridad en TLS 1.0 proporcionan a las empresas el incentivo para deshabilitar TLS 1.0 por completo.

Microsoft recomienda a los clientes que continúen con este problema quitando las dependencias de TLS 1.0 en sus entornos y deshabilitando TLS 1.0 en el nivel de sistema operativo siempre que sea posible. Dado el período de tiempo que TLS 1.0 ha sido compatible con el sector de software, se recomienda encarecidamente que cualquier plan de desuso de TLS 1.0 incluya lo siguiente:

  • Análisis de código para buscar o corregir instancias codificadas de forma rígida de TLS 1.0 o protocolos de seguridad anteriores.

  • Análisis de puntos de conexión de red y análisis de tráfico para identificar sistemas operativos mediante TLS 1.0 o protocolos anteriores.

  • Pruebas de regresión completas a través de toda la pila de aplicaciones con TLS 1.0 deshabilitado.

  • Migración de sistemas operativos heredados y bibliotecas o marcos de desarrollo a versiones capaces de negociar TLS 1.2 de forma predeterminada.

  • Pruebas de compatibilidad entre sistemas operativos usados por su empresa para identificar cualquier problema de soporte técnico de TLS 1.2.

  • Coordinación con sus propios asociados comerciales y clientes para notificarles su decisión de obsoletar TLS 1.0.

  • Comprender qué clientes ya no pueden conectarse a los servidores una vez deshabilitado TLS 1.0.

El objetivo de este documento es proporcionar recomendaciones que pueden ayudar a eliminar los bloqueadores técnicos para deshabilitar TLS 1.0 y, al mismo tiempo, aumentar la visibilidad del impacto de este cambio en sus propios clientes. Completar estas investigaciones puede ayudar a reducir el impacto empresarial de la siguiente vulnerabilidad de seguridad en TLS 1.0. Para los fines de este documento, las referencias al desuso de TLS 1.0 también incluyen TLS 1.1.

Los desarrolladores de software empresarial tienen una necesidad estratégica de adoptar soluciones más seguras y ágiles (también conocidas como Crypto Agility) para abordar los riesgos futuros del protocolo de seguridad. Aunque en este documento se proponen soluciones ágiles para la eliminación de la codificación rígida de TLS, las soluciones más amplias de agilidad criptográfica están fuera del ámbito de este documento.

El estado actual de la implementación de TLS 1.0 de Microsoft

La implementación de TLS 1.0 de Microsoft está libre de vulnerabilidades de seguridad conocidas. Debido a la posibilidad de futuros ataques de degradación del protocolo y otras vulnerabilidades de TLS 1.0 no específicas de la implementación de Microsoft, se recomienda quitar las dependencias de todos los protocolos de seguridad anteriores a TLS 1.2 siempre que sea posible (TLS 1.1/1.0/ SSLv3/SSLv2).

Al planear esta migración a TLS 1.2 y versiones posteriores, los desarrolladores y administradores del sistema deben tener en cuenta la posibilidad de codificación de versión de protocolo en aplicaciones desarrolladas por sus empleados y asociados. La codificación en este caso significa que la versión de TLS se ha corregido a una versión que está obsoleta y menos segura que las versiones más recientes. Las versiones de TLS más recientes que la versión codificada no se pueden usar sin modificar el programa en cuestión. Esta clase de problema no se puede solucionar sin cambios en el código fuente y la implementación de actualizaciones de software. ** La codificación de la versión del protocolo era habitual en el pasado para fines de prueba y compatibilidad, ya que muchos navegadores y sistemas operativos diferentes tenían distintos niveles de soporte para TLS.

Versiones admitidas de TLS en Windows

Muchos sistemas operativos tienen valores predeterminados de versión TLS obsoletos o admiten límites máximos que se deben tener en cuenta.

Figura 1: Compatibilidad del protocolo de seguridad con la versión del sistema operativo

sistema operativo Windows SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista Habilitado Habilitado Habilitado No está soportado No está soportado No está soportado
Windows Server 2008 Habilitado Habilitado Habilitado Deshabilitado* Deshabilitado* No está soportado
Windows 7 (WS2008 R2) Habilitado Habilitado Habilitado Deshabilitado* Deshabilitado* No está soportado
Windows 8 (WS2012) Deshabilitado Habilitado Habilitado Habilitado Habilitado No está soportado
Windows 8.1 (WS2012 R2) Deshabilitado Habilitado Habilitado Habilitado Habilitado No está soportado
Windows 10 Deshabilitado Habilitado Habilitado Habilitado Habilitado No está soportado
Windows 11 Deshabilitado Habilitado Habilitado Habilitado Habilitado Habilitado
Windows Server 2016 No está soportado Deshabilitado Habilitado Habilitado Habilitado No está soportado
Windows Server 2016 No está soportado Deshabilitado Habilitado Habilitado Habilitado No está soportado
Windows Server 2019 No está soportado Deshabilitado Habilitado Habilitado Habilitado No está soportado
Windows Server 2019 GS Edition No está soportado Deshabilitado Deshabilitado Deshabilitado Habilitado No está soportado
Windows Server 2022 No está soportado Deshabilitado Deshabilitado Deshabilitado Habilitado Habilitado

Windows Server 2019 GS Edition es compatible con Microsoft SDL, TLS 1.2 solo con un conjunto restringido de conjuntos de cifrado.

La edición de Windows Server 2022 es compatible con Microsoft SDL, TLS 1.2 y TLS 1.3 solo con un conjunto restringido de conjuntos de cifrado.

TLS 1.1/1.2 se puede habilitar en Windows Server 2008 mediante este paquete opcional de Windows Update.

Para obtener más información sobre el desuso de TLS 1.0/1.1 en IE/Edge, consulte Modernización de conexiones TLS en Microsoft Edge e Internet Explorer 11, cambios que afectan a la compatibilidad del sitio que llegan a Microsoft Edge y deshabilitación de TLS/1.0 y TLS/1.1 en el nuevo explorador perimetral

Una manera rápida de determinar qué versión de TLS solicitarán varios clientes al conectarse a los servicios en línea es haciendo referencia a la simulación de protocolo de enlace en Qualys SSL Labs. Esta simulación abarca las combinaciones de sistema operativo o explorador de cliente entre los fabricantes. Consulte el Apéndice A al final de este documento para obtener un ejemplo detallado en el que se muestran las versiones del protocolo TLS negociadas por varias combinaciones de explorador o sistema operativo cliente simulado al conectarse a www.microsoft.com.

Si aún no se ha completado, se recomienda realizar un inventario de sistemas operativos utilizados por su empresa, clientes y asociados (los dos últimos a través de la comunicación o divulgación o al menos la recopilación de cadenas de User-Agent HTTP). Este inventario se puede complementar aún más mediante el análisis de tráfico en el perímetro de la red empresarial. En tal situación, el análisis del tráfico producirá las versiones de TLS negociadas correctamente por los clientes/asociados que se conectan a los servicios, pero el tráfico en sí permanecerá cifrado.

Mejoras de ingeniería de Microsoft para eliminar las dependencias de TLS 1.0

Desde la versión v1 de este documento, Microsoft ha enviado varias actualizaciones de software y nuevas características compatibles con el desuso de TLS 1.0. Entre ellas se incluyen las siguientes:

  • Registro personalizado de IIS para correlacionar la cadena del agente de usuario o IP del cliente, el URI del servicio, la versión del protocolo TLS y el conjunto de cifrado.

    • Con este registro, los administradores pueden finalmente cuantificar la exposición de sus clientes a TLS débil.

  • SecureScore : para ayudar a los administradores de inquilinos de Office 365 a identificar su propio uso débil de TLS, el portal de SecureScore se ha creado para compartir esta información ya que TLS 1.0 ha salido del soporte técnico en Office 365 en octubre de 2018.

    • Este portal proporciona a los administradores de inquilinos de Office 365 la información valiosa que necesitan para ponerse en contacto con sus propios clientes que pueden no ser conscientes de sus propias dependencias de TLS 1.0.

    • Visite https://securescore.microsoft.com/ para obtener más información.

  • .Net Framework se actualiza para eliminar la codificación de nivel de aplicación y evitar las dependencias de TLS 1.0 heredadas por el marco.

  • Se han publicado instrucciones para desarrolladores y actualizaciones de software para ayudar a los clientes a identificar y eliminar las dependencias de .Net en TLS débiles: procedimientos recomendados de seguridad de la capa de transporte (TLS) con .NET Framework

    • FYI: es probable que todas las aplicaciones destinadas a .NET 4.5 o inferior tengan que modificarse para admitir TLS 1.2.

  • TLS 1.2 se ha retroportado a Windows Server 2008 SP2 y XP POSReady 2009 para ayudar a los clientes con obligaciones heredadas.

  • Se realizarán más anuncios a principios de 2019 y se comunicarán en las actualizaciones posteriores de este documento.

Búsqueda y corrección de dependencias de TLS 1.0 en el código

En el caso de los productos que usan las bibliotecas de criptografía y los protocolos de seguridad proporcionados por el sistema operativo Windows, los pasos siguientes deben ayudar a identificar cualquier uso de TLS 1.0 codificado de forma segura en las aplicaciones:

  1. Identifique todas las instancias de AcquireCredentialsHandle(). Esto ayuda a los revisores a acercarse más a los bloques de código donde TLS se puede codificar de forma rígida.

  2. Revise las instancias de las estructuras SecPkgContext_SupportedProtocols y SecPkgContext_ConnectionInfo para TLS codificados.

  3. En el código nativo, establezca las asignaciones no cero de grbitEnabledProtocols en cero. Esto permite al sistema operativo usar su versión de TLS predeterminada.

  4. Deshabilite el modo FIPS si está habilitado debido al potencial de conflicto con la configuración necesaria para deshabilitar explícitamente TLS 1.0/1.1 en este documento. Consulte el Apéndice B para obtener más información.

  5. Actualice y vuelva a compilar las aplicaciones que usen WinHTTP hospedadas en Server 2012 o versiones anteriores.

    1. Recompile y vuelva a direccionar las aplicaciones administradas contra la versión más reciente de .NET Framework.

    2. Las aplicaciones deben agregar código para admitir TLS 1.2 a través de WinHttpSetOption

  6. Para cubrir todas las bases, examine el código fuente y los archivos de configuración del servicio en línea para los patrones siguientes correspondientes a los valores de tipo enumerados que se usan habitualmente en la codificación rígida TLS:

    1. Tipo de Protocolo de Seguridad

    2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL o PROTOCOL_TLS

La solución recomendada en todos los casos anteriores es quitar la selección de la versión del protocolo codificado de forma predeterminada y aplazarla al valor predeterminado del sistema operativo. Si usa DevSkim, haga clic aquí para ver las reglas que cubren las comprobaciones anteriores que puede usar con su propio código.

Windows PowerShell usa .NET Framework 4.5, que no incluye TLS 1.2 como protocolo disponible. Para solucionar esto, hay dos soluciones disponibles:

  1. Modifique el script en cuestión para incluir lo siguiente:

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

  2. Agregue una clave del Registro para todo el sistema (por ejemplo, a través de la directiva de grupo) a cualquier máquina que necesite realizar conexiones TLS 1.2 desde una aplicación .NET. Esto hará que .NET use las versiones TLS "Predeterminadas del sistema", que agrega TLS 1.2 como protocolo disponible Y permitirá que los scripts usen versiones futuras de TLS cuando el sistema operativo los admita. (por ejemplo, TLS 1.3)

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

Las soluciones (1) y (2) son mutuamente excluyentes, lo que significa que no se deben implementar conjuntamente.

Recompila o retargetiza aplicaciones administradas utilizando la versión más reciente de .Net Framework

Las aplicaciones que usan versiones de .NET Framework anteriores a la 4.7 pueden tener limitaciones que limitan eficazmente la compatibilidad con TLS 1.0, independientemente de los valores predeterminados del sistema operativo subyacentes. Consulte el diagrama siguiente y los procedimientos recomendados de seguridad de la capa de transporte (TLS) con .NET Framework para obtener más información.

Recompilación de aplicaciones administradas

SystemDefaultTLSVersion prevalece sobre la configuración a nivel de aplicación de las versiones TLS. La mejor práctica recomendada es utilizar siempre la versión predeterminada de TLS del sistema operativo. También es la única solución crypto-agile que permite a las aplicaciones aprovechar las ventajas de la compatibilidad futura con TLS 1.3.

Si tiene como destino versiones anteriores de .NET Framework, como 4.5.2 o 3.5, la aplicación usará de forma predeterminada los protocolos anteriores y no recomendados, como SSL 3.0 o TLS 1.0. Se recomienda encarecidamente actualizar a versiones más recientes de .NET Framework, como .NET Framework 4.6 o establecer las claves del Registro adecuadas para "UseStrongCrypto".

Pruebas con TLS 1.2+

Siguiendo las correcciones recomendadas en la sección anterior, los productos deben probarse con regresión para errores de negociación de protocolos y compatibilidad con otros sistemas operativos de su empresa.

  • El problema más común en esta prueba de regresión será un error de negociación TLS debido a un intento de conexión de cliente desde un sistema operativo o explorador que no admite TLS 1.2.

    • Por ejemplo, un cliente de Vista no podrá negociar TLS con un servidor configurado para TLS 1.2 y versiones posteriores, ya que la versión máxima admitida de TLS de Vista es 1.0. Ese cliente debe actualizarse o retirarse en un entorno tls 1.2+.

  • Los productos que usan la autenticación mutua mutua basada en certificados pueden requerir pruebas de regresión adicionales, ya que el código de selección de certificados asociado a TLS 1.0 era menos expresivo que para TLS 1.2.

    • Si un producto negocia MTLS con un certificado de una ubicación no estándar (fuera de los almacenes de certificados con nombre estándar en Windows), ese código puede necesitar actualizar para asegurarse de que el certificado se adquiere correctamente.

  • Las interdependencias de servicio deben revisarse para detectar puntos problemáticos.

    • Todos los servicios que interoperan con servicios de tercero deben realizar pruebas de interoperabilidad adicionales con esos terceros.

    • Cualquier aplicación que no sea Windows o sistemas operativos de servidor en uso requiera investigación o confirmación de que pueden admitir TLS 1.2. El escaneo es la manera más fácil de determinar esto.

Un plano técnico sencillo para probar estos cambios en un servicio en línea consta de lo siguiente:

  1. Realice un examen de los sistemas de entorno de producción para identificar los sistemas operativos que no admiten TLS 1.2.

  2. Examine el código fuente y los archivos de configuración del servicio en línea para TLS codificados de forma rígida, tal como se describe en "Búsqueda y corrección de dependencias de TLS 1.0 en el código".

  3. Actualice o recompile las aplicaciones según sea necesario:

    1. Aplicaciones administradas

      1. Vuelva a compilar con la versión más reciente de .NET Framework.

      2. Compruebe que el uso de la enumeración SSLProtocols esté establecido en SSLProtocols.None para usar la configuración predeterminada del sistema operativo.

    2. Aplicaciones WinHTTP: recompilación con WinHttpSetOption para admitir TLS 1.2

  4. Inicie las pruebas en un entorno de preproducción o ensayo con todos los protocolos de seguridad anteriores a TLS 1.2 deshabilitados mediante el Registro.

  5. Corrija las instancias restantes de la codificación de TLS a medida que se encuentren en las pruebas. Vuelva a implementar el software y realice una nueva ejecución de prueba de regresión.

Notificación a los asociados de los planes de desuso de TLS 1.0

Una vez que se solucione la codificación de TLS y se completen las actualizaciones del sistema operativo o del marco de desarrollo, si opta por dejar de usar TLS 1.0, será necesario coordinarse con los clientes y asociados:

  • La comunicación anticipada con socios y clientes es esencial para una desactivación planificada de TLS 1.0. Como mínimo, esto debe constar de publicaciones de blog, notas del producto u otro contenido web.

  • Cada uno de los asociados debe evaluar su propia preparación de TLS 1.2 a través de las iniciativas de pruebas de regresión o análisis de código o sistema operativo que se describen en las secciones anteriores.

Conclusión

Quitar las dependencias de TLS 1.0 es un problema complicado para gestionar completamente. Microsoft y los asociados del sector están tomando medidas sobre esto hoy para asegurarse de que toda la pila de productos es más segura de forma predeterminada, desde nuestros componentes del sistema operativo y marcos de desarrollo hasta las aplicaciones o servicios basados en ellos. Seguir las recomendaciones establecidas en este documento ayudará a su empresa a seguir el rumbo correcto y a saber qué desafíos esperar. También ayudará a sus propios clientes a prepararse para la transición.

Apéndice A: Simulación de apretón de manos para varios clientes que se conectan a www.microsoft.com, cortesía de SSLLabs.com

Resultados de la simulación de handshake

Apéndice B: Desuso de TLS 1.0/1.1 mientras se conserva el modo FIPS

Siga los pasos siguientes si la red requiere el modo FIPS, pero también quiere dejar de usar TLS 1.0/1.1:

  1. Configure las versiones de TLS a través del Registro estableciendo "Habilitado" en cero para las versiones de TLS no deseadas.

  2. Deshabilite la curva 25519 (solo Server 2016) a través de la Directiva de Grupo.

  3. Deshabilite todos los conjuntos de cifrado mediante algoritmos que no estén permitidos por la publicación FIPS correspondiente. Para Server 2016 (suponiendo que la configuración predeterminada está en vigor), esto significa deshabilitar los cifrados RC4, PSK y NULL.

Colaboradores/gracias a

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson

  • Last updated on