Solución del problema con TLS 1.0, 2.ª edición

  • Artículo

En este documento se presentan las instrucciones más recientes sobre la identificación y eliminación rápidas de las dependencias de la versión 1.0 del protocolo de Seguridad de la capa de transporte (TLS) del software basado en los sistemas operativos de Microsoft. Para ello, se realiza un seguimiento de los detalles de los cambios en los productos y las nuevas características que ofrece Microsoft para proteger a sus 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 con la versión de TLS 1.2 y posteriores. Aunque las soluciones descritas aquí pueden guiarle y ayudarle en la eliminación del uso de TLS 1.0 de los sistemas operativos que no son de Microsoft o las bibliotecas criptográficas, este documento no se centra en ello.

TLS 1.0 es un protocolo de seguridad definido por primera vez en 1999 para establecer canales de cifrado a través de redes de equipos. Microsoft ha ofrecido compatibilidad con este protocolo desde Windows XP/Server 2003. Aunque ya no es el protocolo de seguridad predeterminado que usan los sistemas operativos modernos, TLS 1.0 todavía se admite con fines de compatibilidad con versiones anteriores. La evolución de los requisitos normativos, así como las nuevas vulnerabilidades de seguridad en TLS 1.0, proporcionan a las organizaciones el incentivo para deshabilitar TLS 1.0 por completo.

Microsoft recomienda a los clientes que, para olvidarse de este problema, eliminen las dependencias de TLS 1.0 de sus entornos y deshabiliten TLS 1.0 a nivel del sistema operativo si es posible. Teniendo en cuenta la cantidad de tiempo que el sector de software ha ofrecido compatibilidad con TLS 1.0, es muy recomendable que todos los planes de desuso de TLS 1.0 incluyan 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.

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

  • Pruebas de regresión completas a lo largo de toda la pila de aplicaciones con TLS 1.0 deshabilitado.

  • Migración de sistemas operativos y marcos o bibliotecas de desarrollo heredados a las versiones que puedan administrar TLS 1.2 de forma predeterminada.

  • Pruebas de compatibilidad en los sistemas operativos que usa su empresa para identificar cualquier problema de compatibilidad con TLS 1.2.

  • Coordinación con sus propios asociados y clientes empresariales para notificarles su cambio para dejar de usar TLS 1.0.

  • Descripción sobre los clientes que es posible que ya no puedan conectarse a sus servidores una vez que se haya deshabilitado TLS 1.0.

El objetivo de este documento es proporcionar recomendaciones que ayuden a eliminar los impedimentos técnicos para deshabilitar TLS 1.0 y, al mismo tiempo, aumentar la visibilidad del impacto de este cambio en sus clientes. La realización de 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 ágiles y seguras de cara al futuro (lo que se conoce también como agilidad criptográfica) para abordar nuevos riesgos en protocolos de seguridad. Aunque este documento propone soluciones ágiles para la eliminación de la codificación de forma rígida de TLS, las soluciones de agilidad criptográfica más amplias quedan fuera del ámbito de este documento.

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 la migración a TLS a partir de la versión 1.2, los desarrolladores y administradores del sistema deben tener en cuenta la posibilidad de que la versión del protocolo se haya codificado de forma rígida en las aplicaciones que desarrollan sus empleados y asociados. En este caso, la codificación rígida significa que la versión de TLS se ha fijado a una versión obsoleta y menos segura que las versiones más recientes. Las versiones de TLS más recientes que la versión codificada de forma rígida no se pueden usar sin modificar el programa en cuestión. Este tipo de problema no se puede solucionar sin realizar cambios en el código fuente y en la implementación de las actualizaciones de software. La codificación de forma rígida de la versión del protocolo era habitual en el pasado con fines de prueba y compatibilidad, ya que muchos exploradores y sistemas operativos diferentes tenían distintos niveles de compatibilidad con TLS.

Versiones admitidas de TLS en Windows

Muchos sistemas operativos tienen versiones predeterminadas de TLS obsoletas o límites de compatibilidad que se deben tener en cuenta.

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

SO Windows SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista Habilitado habilitado Habilitado No compatible No compatible No compatible
Windows Server 2008 Habilitado habilitado Habilitado Deshabilitado* Deshabilitado* No compatible
Windows 7 (WS2008 R2) Habilitado habilitado Habilitado Deshabilitado* Deshabilitado* No compatible
Windows 8 (WS2012) Deshabilitado habilitado habilitado habilitado Habilitado No compatible
Windows 8.1 (WS2012 R2) Deshabilitado habilitado habilitado habilitado Habilitado No compatible
Windows 10 Deshabilitado habilitado habilitado habilitado Habilitado No compatible
Windows 11 Deshabilitado habilitado habilitado habilitado habilitado Habilitado
Windows Server 2016 No compatible Deshabilitado habilitado habilitado Habilitado No compatible
Windows Server 2016 No compatible Deshabilitado habilitado habilitado Habilitado No compatible
Windows Server 2019 No compatible Deshabilitado habilitado habilitado Habilitado No compatible
Edición Windows Server 2019 GS No compatible Deshabilitado Disabled Deshabilitado Habilitado No compatible
Windows Server 2022 No compatible Deshabilitado Disabled Deshabilitado habilitado Habilitado

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

La edición 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, Próximos cambios que afectan la compatibilidad de los sitios en Microsoft Edge y Deshabilitar TLS/1.0 y TLS/1.1 en el nuevo explorador Edge.

Una forma rápida de determinar la versión de TLS que solicitarán varios clientes al conectarse a sus servicios en línea es consultando la simulación del protocolo de enlace en Qualys SSL Labs. Esta simulación cubre combinaciones de sistemas operativos del cliente y exploradores entre fabricantes. Consulte el Apéndice A al final de este documento para ver un ejemplo detallado en el que se muestran las versiones del protocolo TLS que administran varias combinaciones simuladas de sistema operativo del cliente o explorador al conectarse a www.microsoft.com.

Si aún no lo ha hecho, le recomendamos que realice un inventario de los sistemas operativos que usan su empresa, clientes y asociados (para los dos últimos, debería comunicarse con ellos o al menos recopilar las cadenas de agente de usuario HTTP). Este inventario puede complementarse aún más mediante el análisis de tráfico en el perímetro de la red de su empresa. En tal situación, el análisis de tráfico revelará las versiones de TLS administradas correctamente por los clientes o asociados que se conectan a los servicios, pero el tráfico propiamente permanecerá cifrado.

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

Desde la primera versión de este documento, Microsoft ha distribuido una serie de actualizaciones de software y nuevas características a favor del desuso de TLS 1.0. Entre ellas se incluyen las siguientes:

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

    • Con este registro, los administradores finalmente pueden cuantificar la exposición de sus clientes a un protocolo TLS no seguro.

  • Secure Score: con tal de ayudar a los administradores de inquilinos de Office 365 a identificar el uso que hacen de su versión de TLS no segura, se ha creado el portal Secure Score para compartir esta información, ya que se dejó de ofrecer la compatibilidad de Office 365 con TLS 1.0 en octubre de 2018.

    • Este portal proporciona a los administradores de inquilinos de Office 365 la información que necesitan para ponerse en contacto con sus propios clientes, que es posible que no conozcan sus dependencias de TLS 1.0.

    • Para obtener más información, visite https://securescore.microsoft.com/.

  • Actualizaciones de .NET Framework para eliminar la codificación de forma rígida a nivel de aplicación y evitar dependencias de TLS 1.0 heredadas por el marco.

  • Se han publicado guías para desarrolladores y actualizaciones de software para ayudar a los clientes a identificar y eliminar las dependencias de .Net en TLS débil: Procedimientos recomendados sobre la seguridad de la capa de transporte (TLS) con .NET Framework.

    • NOTA: Es probable que sea necesario modificar todas las aplicaciones destinadas a .NET 4.5 o versiones anteriores para que sean compatibles con TLS 1.2.

  • TLS 1.2 se ha incorporado a Windows Server 2008 SP2 y XP POSReady 2009 para ayudar a aquellos 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 que proporciona el sistema operativo Windows, los siguientes pasos deberían ayudar a identificar cualquier uso de TLS 1.0 codificado de forma rígida en sus aplicaciones:

  1. Identifique todas las instancias de AcquireCredentialsHandle(). De este modo, los revisores pueden aproximarse más a los bloques de código en los que es posible que TLS esté codificado de forma rígida.

  2. Revise las instancias de las estructuras SecPkgContext_SupportedProtocols y SecPkgContext_ConnectionInfo para detectar versiones de TLS codificadas de forma rígida.

  3. En código nativo, establezca cualquier asignación distinta de cero de grbitEnabledProtocols en cero. Esto permite que el sistema operativo use su versión de TLS predeterminada.

  4. Deshabilite el modo FIPS si está habilitado,ya que puede que entre en 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 recompile las aplicaciones que usen WinHTTP hospedado en Server 2012 o versiones anteriores.

    1. Aplicaciones administradas: recompílelas y vuelva a definir su destino con la última versión de .NET Framework.

    2. Las aplicaciones deben agregar código para ser compatibles con TLS 1.2 mediante WinHttpSetOption.

  6. Para cubrir todas las bases, examine en el código fuente y los archivos de configuración de los servicios en línea los patrones siguientes, que corresponden a los valores de tipo enumerado que se usan habitualmente para codificar de forma rígida la versión de TLS:

    1. SecurityProtocolType

    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 codificada de forma rígida y usar el valor predeterminado del sistema operativo. Si usa DevSkim, haga clic aquí para ver las reglas que cubren las comprobaciones anteriores y 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 solucionarlo, hay dos opciones disponibles:

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

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

  2. Agregue una clave del registro para todo el sistema (por ejemplo, mediante la directiva de grupo) a cualquier máquina que deba establecer conexiones TLS 1.2 desde una aplicación de .NET. Esto hará que .NET use las versiones de TLS "predeterminadas del sistema" que agregan TLS 1.2 como protocolo disponible y permiten que los scripts usen versiones de TLS futuras cuando el sistema operativo sea compatible con ellas. (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 excluyentes mutuamente, lo que significa que se deben implementar juntas.

Recompilación/nuevo destino de las aplicaciones administradas con la versión más reciente de .NET Framework

Las aplicaciones que usan versiones de .NET Framework anteriores a la versión 4.7 pueden tener restricciones que limiten de forma eficaz la compatibilidad con TLS 1.0, independientemente de los valores predeterminados del sistema operativo subyacente. Consulte el siguiente diagrama y Procedimientos recomendados sobre la seguridad de la capa de transporte (TLS) con .NET Framework para obtener más información.

Recompilación de aplicaciones administradas

SystemDefaultTLSVersion tiene prioridad sobre la selección de destino de nivel de aplicación de las versiones de TLS. El procedimiento recomendado es usar siempre la versión de TLS predeterminada del sistema operativo. También es la única solución de agilidad criptográfica que permite que las aplicaciones aprovechen la futura compatibilidad con TLS 1.3.

Si se dirige a versiones anteriores de .NET Framework, como la 4.5.2 o 3.5, de forma predeterminada, la aplicación usará los protocolos anteriores que no se recomiendan, como SSL 3.0 o TLS 1.0. Se recomienda 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 la versión de TLS 1.2 y posteriores

Después de aplicar las correcciones recomendadas en la sección anterior, deben realizarse pruebas de regresión en los productos para detectar errores de negociación del protocolo y comprobar la compatibilidad con otros sistemas operativos de la empresa.

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

    • Por ejemplo, un cliente con Vista no podrá administrar TLS con un servidor configurado para TLS 1.2 y sus versiones posteriores, ya que la versión máxima de TLS compatible con Vista es la 1.0. En un entorno con TLS 1.2 o sus versiones posteriores, ese cliente debe actualizarse o retirarse.

  • Es posible que sea necesario realizar pruebas de regresión adicionales para los productos que usan la autenticación TLS mutua basada en certificados, ya que el código de selección de certificados asociado con TLS 1.0 era menos expresivo que el de TLS 1.2.

    • Si un producto administra MTLS con un certificado desde una ubicación no estándar (fuera de los almacenes de certificados con nombre estándar en Windows), es posible que sea necesario actualizar el código para asegurarse de que el certificado se adquiere correctamente.

  • Deben revisarse las interdependencias entre servicios a fin de detectar problemas.

    • Los servicios que interoperan con servicios de terceros deben realizar pruebas de interoperabilidad adicionales con dichos terceros.

    • Se debe investigar y confirmar que cualquier aplicación o sistema operativo de servidor en uso que no sea Windows admita TLS 1.2. Para determinarlo, lo más fácil es realizar un examen.

Un proyecto sencillo para probar estos cambios en un servicio en línea consta de los pasos siguientes:

  1. Realice un análisis de los sistemas del entorno de producción para identificar los sistemas operativos que no son compatibles con TLS 1.2.

  2. Examine el código fuente y los archivos de configuración del servicio en línea para buscar versiones de TLS codificadas de forma rígida 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. Recompílelas con la versión más reciente de .NET Framework.

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

    2. Aplicaciones de WinHTTP: recompílelas con WinHttpSetOption para que sean compatibles con TLS 1.2.

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

  5. Corrija el resto de instancias de codificación de forma rígida de TLS a medida que las encuentre en las pruebas. Vuelva a implementar el software y realice una nueva serie de pruebas de regresión.

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

Una vez que se haya solucionado la codificación rígida de TLS y se hayan completado las actualizaciones del sistema operativo o del marco de desarrollo, si decide dejar de usar TLS 1.0, deberá coordinarse con sus clientes y asociados:

  • La comunicación desde el principio con los asociados y los clientes es fundamental para una implementación correcta del desuso de TLS 1.0. Como mínimo, la información debe constar de entradas de blog, notas del producto u otro contenido web.

  • Cada uno de los asociados tiene que evaluar su propia preparación para TLS 1.2 mediante las iniciativas del sistema operativo, examen del código y pruebas de regresiones descritas en las secciones anteriores.

Conclusión

La eliminación de dependencias de TLS 1.0 es un problema complicado de resolver de principio a fin. Actualmente, Microsoft y los asociados del sector están tomando medidas al respecto para asegurarse de que toda la pila de productos es más segura de forma predeterminada (desde los componentes del sistema operativo y los marcos de desarrollo hasta las aplicaciones y servicios creados a partir de ellos). Las recomendaciones que se indican en este documento permitirán que su empresa tome el camino correcto y conozca los retos que pueden esperarle. También ayudarán a sus propios clientes a estar más preparados para la transición.

Anexo A: simulación de protocolo de enlace para varios clientes que se conectan a www.microsoft.com, por cortesía de SSLLabs.com

Resultados de la simulación del protocolo de enlace

Anexo B: Desuso de TLS 1.0/1.1 con conservación del modo FIPS

Siga los pasos que se indican a continuación si su red requiere el modo FIPS, pero también quiere dejar de usar TLS 1.0/1.1:

  1. Configure las versiones de TLS desde el Registro. Para ello, establezca la opción "Enabled" en cero para las versiones de TLS no deseadas.

  2. Deshabilite Curve25519 (solo Server 2016) mediante la directiva de grupo.

  3. Deshabilite cualquier conjunto de cifrado que use algoritmos no permitidos por la publicación de FIPS correspondiente. En el caso de Server 2016 (suponiendo que la configuración predeterminada está en vigor), esto significa que se deben deshabilitar los cifrados RC4, PSK y NULL.

Colaboradores/agradecimientos

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