Solución del problema tls 1.0, segunda edición

Por Andrew Marshall
Administrador de programas de seguridad principal
Microsoft Corporation

Resumen ejecutivo

Este documento presenta 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) versión 1.0 en el software integrado en los sistemas operativos de Microsoft, siguiendo los detalles sobre los cambios del producto y las nuevas características entregadas por 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 debatan aquí pueden llevar a cabo y ayudar a eliminar el uso de TLS 1.0 en sistemas operativos que no sean de Microsoft o bibliotecas de cifrado, no son un foco de este documento.

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 admitido 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 sigue siendo compatible con la 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 empresas el incentivo de deshabilitar TLS 1.0 por completo.

Microsoft recomienda a los clientes que se adelanten a este problema quitando las dependencias de TLS 1.0 en sus entornos y deshabilitando TLS 1.0 en el nivel del sistema operativo siempre que sea posible. Dado el 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 TLS 1.0 o protocolos de seguridad anteriores.

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

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

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

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

• Coordinación con sus propios socios empresariales y clientes para notificarles su cambio a TLS 1.0 en desuso.

• Comprender qué clientes pueden ya no poder conectarse a sus servidores una vez que TLS 1.0 está deshabilitado.

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 sobre el impacto de este cambio para 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.

Enterprise desarrolladores de software tienen una necesidad estratégica de adoptar soluciones más ágiles y seguras para el futuro (también conocidas como agilidad de cifrado) para hacer frente a futuros compromisos del protocolo de seguridad. Aunque este documento propone soluciones ágiles para la eliminación de la negociación de tls, las soluciones más amplias de agilidad de criptografía 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+, los desarrolladores y los administradores del sistema deben ser conscientes de la posibilidad de que la versión de protocolo se reescinda en aplicaciones desarrolladas por sus empleados y asociados. La compatibilidad aquí significa que la versión de TLS se ha corregido en una versión que está obsoleta y es menos segura que las versiones más recientes. Las versiones 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 los cambios en el código fuente y la implementación de actualización de software. La programación de la versión de protocolo era algo común en el pasado para las pruebas y la compatibilidad, ya que muchos exploradores y sistemas operativos diferentes tenían distintos niveles de compatibilidad con TLS.

Garantizar la compatibilidad con TLS 1.2 en todos los sistemas operativos implementados

Muchos sistemas operativos tienen versiones de TLS obsoletas predeterminadas o techos de soporte técnico que deben tenerse en cuenta. El uso de Windows 8/Server 2012 o posterior significa que TLS 1.2 será la versión predeterminada del protocolo de seguridad:

Figura 1: Soporte técnico del protocolo de seguridad por versión del sistema operativo

*TLS 1.1/1.2 se puede habilitar en Windows Server 2008 a través de este paquete Windows actualización opcional.

Para obtener más información sobre el desuso de TLS 1.0/1.1 en IE/Edge, vea 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 Deshabilitar TLS/1.0 y TLS/1.1 en el nuevo explorador perimetral

Una forma rápida de determinar qué versión de TLS solicitarán varios clientes al conectarse a sus servicios en línea es haciendo referencia a la Simulación de apretón de manos en Qualys SSL Labs. Esta simulación trata las combinaciones de sistemas operativo y exploradores del cliente entre los fabricantes. Vea el Apéndice A al final de este documento para obtener un ejemplo detallado que muestra las versiones del protocolo TLS negociadas por varias combinaciones de sistema operativo/explorador de cliente simuladas al conectarse a www.microsoft.com.

Si aún no está completo, es muy recomendable realizar un inventario de los sistemas operativos usados por la empresa, los clientes y los partners (los dos últimos a través de la difusión/comunicación o al menos la colección de cadenas HTTP User-Agent). Este inventario se puede complementar con análisis de tráfico en el perímetro de red empresarial. En tal situación, el análisis de tráfico dará como resultado que los clientes o partners que se conecten a sus servicios negocien correctamente las versiones TLS, 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 una serie de actualizaciones de software y nuevas características para admitir el desuso de TLS 1.0. Estos incluyen:

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

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

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

  • Este portal proporciona Office 365 administradores de inquilinos con la información valiosa que necesitan para comunicarse con sus propios clientes que pueden desconocer sus propias dependencias de TLS 1.0.

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

• .Net Framework se actualiza para eliminar el hardcoding a nivel de aplicación y evitar las dependencias de TLS 1.0 heredadas del marco.

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

  • FYI: Es probable que todas las aplicaciones dirigidas a .NET 4.5 o a continuación tengan que modificarse para admitir TLS 1.2.

• TLS 1.2 se ha vuelto a usar 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.

Buscar y corregir dependencias de TLS 1.0 en código

Para los productos que usan las bibliotecas de criptografía y protocolos de seguridad proporcionados por el sistema operativo Windows, los pasos siguientes deben ayudar a identificar cualquier uso de TLS 1.0 codificado 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 en los que TLS puede estar codificado.

2. Revise todas las instancias de las SecPkgContext_SupportedProtocols y SecPkgContext_ConnectionInfo de TLS codificado.

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

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

5. Actualice y vuelva a compilar cualquier aplicación que use WinHTTP hospedado en Server 2012 o versiones anteriores.

   1. Aplicaciones administradas: recompilar y volver a dirigirse a la última .NET Framework versión

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

6. Para cubrir todas las bases, escanee 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 de código fuente 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 versiones del protocolo codificado y diferir al valor predeterminado del sistema operativo. Si usa DevSkim, hagaclic aquí para ver las reglas que cubren las comprobaciones anteriores que puede usar con su propio código.

Actualizar Windows PowerShell scripts o configuración del Registro relacionada

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

1.  Modify the script in question to include the following:
    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

2.  Add a system-wide registry key (e.g. via group policy) to any machine that needs to make TLS 1.2 connections from a .NET app. This will cause .NET to use the "System Default" TLS versions which adds TLS 1.2 as an available protocol AND it will allow the scripts to use future TLS Versions when the OS supports them. (e.g. 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) se excluyen mutuamente, lo que significa que no deben implementarse conjuntamente.

Recompilar/volver a dirigir aplicaciones administradas con 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 limitando de forma efectiva la compatibilidad con TLS 1.0 independientemente de los valores predeterminados subyacentes del sistema operativo. Consulte el siguiente diagrama y https://docs.microsoft.com/dotnet/framework/network-programming/tls para obtener más información.

SystemDefaultTLSVersion tiene prioridad sobre la segmentación a nivel de aplicación de las versiones de TLS. El procedimiento recomendado es diferir siempre a la versión predeterminada de TLS del sistema operativo. También es la única solución de crypto-agile que permite a sus aplicaciones aprovechar el futuro soporte de TLS 1.3.

Si está dirigido a versiones anteriores de .NET Framework como 4.5.2 o 3.5, la aplicación usará de forma predeterminada los protocolos antiguos 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 de 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 comprobar si hay errores de negociación de protocolos y compatibilidad con otros sistemas operativos de su empresa.

• El problema más común en estas pruebas 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+ ya que la versión tls máxima compatible de Vista es 1.0. Ese cliente debe actualizarse o retirarse en un entorno TLS 1.2+.

• Los productos que usan autenticación TLS mutua basada en certificados pueden requerir pruebas de regresión adicionales, 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 negocia MTLS con un certificado de una ubicación no estándar (fuera de los almacenes de certificados con nombre estándar en Windows), es posible que ese código necesite actualizarse para asegurarse de que el certificado se adquiere correctamente.

• Las interdependencias del servicio deben revisarse para ver si hay problemas.

  • Cualquier servicio que interopera con los servicios 3^rd-party debe realizar pruebas de interoperabilidad adicionales con esas partes 3^rd.

  • Cualquier aplicación o Windows operativos de servidor que no se usen requiere investigación o confirmación de que pueden admitir TLS 1.2. El análisis es la forma más sencilla de determinar esto.

Un plano sencillo para probar estos cambios en un servicio en línea consiste en lo siguiente:

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

2. Analizar el código fuente y los archivos de configuración del servicio en línea para TLS codificados de forma rígida, como se describe en " Buscar y corregir dependenciasde TLS 1.0 en código"

3. Actualizar o volver a compilar aplicaciones según sea necesario:

   1. Aplicaciones administradas

      1. Recompilar con la última .NET Framework versión.

      2. Compruebe que cualquier uso de la enumeración SSLProtocols se establece en SSLProtocols.None para usar la configuración predeterminada del sistema operativo.

   2. Aplicaciones de WinHTTP: recompilar con WinHttpSetOption para admitir TLS 1.2

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

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

Notificar a los partners de los planes de desuso de TLS 1.0

Una vez que se solucione el hardcoding de TLS y se hayan completado las actualizaciones del sistema operativo o del marco de desarrollo, si opta por dejar de usar TLS 1.0, será necesario coordinarlo con clientes y partners:

• El acercamiento anticipado entre partners y clientes es esencial para una implementación correcta de desuso de TLS 1.0. Como mínimo, esto debe constar de publicaciones de blog, documentos blancos u otro contenido web.

• Los partners necesitan evaluar su propia preparación de TLS 1.2 a través de las iniciativas de prueba de detección de código o de sistema operativo descritas en las secciones anteriores.

Conclusión

Quitar dependencias de TLS 1.0 es un problema complicado para la unidad de extremo a extremo. Microsoft y los partners del sector están tomando medidas al respecto hoy para asegurarse de que toda la pila de productos es más segura de forma predeterminada, desde nuestros componentes y marcos de desarrollo del sistema operativo hasta las aplicaciones o servicios integrados en ellos. Seguir las recomendaciones realizadas en este documento ayudará a su empresa a trazar el curso correcto y a saber qué retos puede esperar. También ayudará a sus propios clientes a estar más preparados 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 SSLLabs.com

Apéndice B: Desusar TLS 1.0/1.1 conservando el modo FIPS

Siga los pasos siguientes si su red requiere el modo FIPS, pero también desea 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 TLS no deseadas.

2. Deshabilite curva 25519 (solo servidor 2016) a través de la directiva de grupo.

3. Deshabilite cualquier conjunto de conjuntos de cifrado con algoritmos que no están permitidos por la publicación FIPS relevante. Para Server 2016 (suponiendo que la configuración predeterminada esté en vigor), 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