¿Cómo deshabilito TLS 1.0 sin romper RDP?

48

Nuestro procesador de tarjetas de crédito nos notificó recientemente que, a partir del 30 de junio de 2016, tendremos que desactivar TLS 1.0 para seguir cumpliendo con PCI . Intenté ser proactivo deshabilitando TLS 1.0 en nuestra máquina Windows Server 2008 R2, solo para descubrir que inmediatamente después del reinicio no pude conectarme completamente a través del Protocolo de escritorio remoto (RDP). Después de algunas investigaciones, parece que RDP solo es compatible con TLS 1.0 (ver aquí o aquí ), o al menos no está claro cómo habilitar RDP sobre TLS 1.1 o TLS 1.2. ¿Alguien sabe una forma de deshabilitar TLS 1.0 en Windows Server 2008 R2 sin romper RDP? ¿Microsoft planifica soporte para RDP sobre TLS 1.1 o TLS 1.2?

Nota: Parece que hay una forma de hacerlo configurando el servidor para usar la capa de seguridad RDP, pero eso deshabilita la autenticación de nivel de red , que parece intercambiar un mal por otro.

ACTUALIZACIÓN 1 : Microsoft ahora ha abordado este problema. Vea la respuesta a continuación para la actualización del servidor relevante.

ACTUALIZACIÓN 2 : Microsoft ha publicado un tutorial sobre el soporte de SQL Server para PCI DSS 3.1 .

Miguel
fuente
Mis disculpas a todos: las instrucciones que publiqué solo son válidas para Win8 / Server2012 / 2012R2 ... no funcionan en 2008R2 / Win7. Probé 2008R2 y no es lo mismo. Lo siento.
Ryan Ries
Y tenga en cuenta que en 2012, como se menciona en las operaciones, eliminar TLS 1.0 obliga a RDP a rebajar a la capa de seguridad RDP.
Jim B
Hice lo mismo y no puedo ingresar a mi servidor (AWS), ¿pudiste encontrar una manera de ingresar sin acceso físico?
Thomas Paine
1
Según este artículo de soporte, Microsoft acaba de parchear SQL 2012 y 2014 para trabajar con TLS 1.1 y 1.2 support.microsoft.com/en-us/kb/3052404
CarlR
1
@CarlR ese artículo no parece mencionar específicamente RDP'ing para el servidor. De hecho, parece ser específico para la conectividad de la base de datos en sí misma, ya que menciona: "Esta actualización agrega la compatibilidad con el protocolo de Seguridad de la capa de transporte (TLS) versión 1.2 a SQL Server 2014 y al controlador ODBC de Microsoft para SQL Server".
k1DBLITZ

Respuestas:

19

Microsoft lanzó el parche para este problema 15 de septiembre de 2015

Ver https://support.microsoft.com/en-us/kb/3080079

Eric Winn
fuente
Muchas gracias Después de instalar estas actualizaciones, la pantalla tsconfig.msc no muestra signos de TLS 1.1 o TLS 1.2. ¿Alguien pudo confirmar que se está conectando al servidor usando RDP sobre TLS 1.2? Sé que podemos verificar deshabilitando el protocolo TLS temprano en el servidor. Pero si no funciona, no puede usar remotamente RDP en el servidor.
Nirlep
Es posible que cuando seleccione la opción "Negociar", se comunicará el nivel más alto posible, que podría ser TLS 1.2
Nirlep
1
Puede habilitar el registro de Schannel para ver qué versión se está utilizando. El enlace de cómo hacer esto se muestra en mi respuesta.
CarlR
Sé que es un hilo viejo pero ... Tengo un Windows Server 2008 R2 anterior que estoy sacando a relucir. He instalado KB3080079 y ahora deshabilitaré TLS 1.0. Pero no estoy seguro de si la configuración del servidor RDP debe establecerse en "Negociar" o "TLS".
Chris Harrington
15

He estado investigando esto durante un par de días ya que tenemos que cumplir con PCI-DSS 3.1 que requiere que TLS 1.0 esté deshabilitado.

Tampoco queremos recurrir a la capa de seguridad RDP, que es un problema importante de seguridad.

Finalmente logré encontrar documentación que confirme que TLS 1.1 y TLS 1.2 SON compatibles con RDP. Esta documentación está oculta en un registro SChannel y una especificación muy detallada para RDP .

Hay una falta total de documentación de flujo principal en Technet u otros sitios de Microsoft, por lo que esperamos que documentar esto aquí pueda ayudar a algunas personas.

Extractos relevantes de los enlaces proporcionados:

Desde el enlace de MSDN:

"RDP supports four External Security Protocols: TLS 1.0 ([RFC2246]) TLS 1.1 ([RFC4346])<39>, TLS 1.2 ([RFC5246])<40>"

Del PDF de especificación RDP:

"When Enhanced RDP Security is used, RDP traffic is no longer protected by using the techniques
described in section 5.3. Instead, all security operations (such as encryption and decryption, data
integrity checks, and Server Authentication) are implemented by one of the following External
Security Protocols:
TLS 1.0 (see [RFC2246])
TLS 1.1 (see [RFC4346])
TLS 1.2 (see [RFC5246])
CredSSP (see [MS-CSSP])"

"<39> Section 5.4.5: TLS 1.1 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista and Windows Server 2008.
<40> Section 5.4.5:  TLS 1.2 is not supported by Windows NT, Windows 2000 Server, Windows XP,
Windows Server 2003, Windows Vista, and Windows Server 2008"

Por lo tanto, se podría concluir que puede usar TLS 1.1 o 1.2 en Windows Server 2008 R2 de acuerdo con esta documentación.

Sin embargo, nuestras pruebas han demostrado que esto NO funciona desde el cliente RDP de Windows 7 (versión 6.3.9600) cuando TLS 1.0 está deshabilitado y la opción de seguridad RDP está configurada para requerir TLS 1.0.

Esto es, por supuesto, además de habilitar TLS 1.1 y 1.2 que están desactivados de forma predeterminada en 2008R2; de paso, lo hacemos utilizando la muy útil herramienta de cifrado IIS de Nartac Software .

Al analizar este problema, es útil habilitar el registro de SChannel para ver más detalles de lo que sucede cuando se abre la sesión.

Puede establecer el registro de SChannel cambiando la clave HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ EventLogging a 5 y reiniciando.

Una vez hecho esto, puede observar eventos SChannel que muestran la versión TLS que se utiliza cuando se realiza una conexión RDP. Una vez que el registro está habilitado, puede observar el error SChannel cuando el cliente RDP intenta establecer una conexión en Windows 2008 R2 con TLS 1.0 deshabilitado:

A fatal error occurred while creating an SSL server credential. The internal error state is 10013.

También probé la desactivación de TLS 1.0 en Windows Server 2012 y 2012 R2, que puedo confirmar que funciona perfectamente con Windows 7 RDP Client. La entrada del registro SChannel muestra que se está utilizando TLS 1.2:

An SSL server handshake completed successfully. The negotiated cryptographic parameters are as follows.

   Protocol: TLS 1.2
   CipherSuite: 0xC028
   Exchange strength: 256

Espero que esto ayude a alguien que está buscando aclaraciones sobre esto.

Seguiré buscando cómo podríamos hacer que RDP funcione sobre TLS 1.1 y TLS 1.2 en Windows Server 2008 R2.

ACTUALIZACIÓN: 2015-AGO-05

Planteamos el problema de que RDP no funciona con Server 2008 R2 con soporte de Microsoft, incluidos los pasos para reproducir.

Después de varias semanas de retroceso y avance, finalmente recibimos una llamada telefónica del equipo de soporte técnico hoy para reconocer que de hecho podrían reproducirlo y ahora se clasifica como un error. Se lanzará un parche de actualización, en este momento se espera esto en octubre de 2015. Tan pronto como tenga un artículo de KB u otros detalles, los agregaré a esta publicación.

Con suerte, aquellos atrapados en Windows Server 2008 R2 al menos pueden resolver esto antes de la fecha límite de junio de 2016 una vez que se publique el parche.

ACTUALIZACIÓN: 19 de septiembre de 2015

Microsoft finalmente ha publicado un artículo de soporte kb sobre esto aquí y puedo confirmar que funciona bien.

CarlR
fuente
Su última actualización indica "He probado Windows 7 y Windows 2012 R2 y no funciona; todavía se conecta usando TLS1". ¿Alguna vez pudiste hacer que esto funcione?
Doug S
Alguien más puso ese comentario, lo acabo de eliminar ya que funciona bien para nosotros ahora sobre TLS1.2.
CarlR
Hmmm Nunca pude hacerlo funcionar, incluso con estos cambios / actualizaciones y todo lo demás que pude encontrar.
Doug S
El registro de SChannel se puede encontrar en el registro del sistema.
Ivan Chau
8

En su lugar, use IPsec, ya que el documento recomienda: "Configurar primero una sesión fuertemente encriptada (p. Ej., Túnel IPsec) y luego enviar datos a través de SSL dentro de un túnel seguro"

La razón principal para hacer esto sobre la configuración de TLS para RDP es que la política de firewall se audita fácilmente para el cumplimiento (frente a probar que una gran cantidad de cambios en el registro son compatibles) e IPsec es bastante fácil de configurar en Windows.

Si necesita el cumplimiento completo de la suite B, IPSEC con tls 1.0 es la única forma disponible para aplicar a las longitudes de certificado apropiadas

Jim B
fuente
El túnel sobre SSH también es una opción que mencionaré. (Requiere software de servidor SSH para Windows, por supuesto.)
Chris W. Rea
IPsec no es SSH
Jim B
3
Correcto, y no quise dar a entender que son lo mismo. Más bien, SSH es un método alternativo para establecer un túnel seguro a un servidor.
Chris W. Rea
@ JimB Lo siento, tenías razón.
Ryan Ries
1
@RyanRies Np, todavía me estoy rascando la cabeza sobre cómo otros 12 votarían sin saber que funcionó.
Jim B
8

Esta no es una respuesta a la pregunta, sino a la subpregunta "¿Cómo restauro el acceso remoto a una máquina virtual donde he desactivado TLS 1.0 y sin acceso físico?".

Inhabilité TLS 1.0 usando IISCrypto, que dio una advertencia útil sobre el efecto secundario de que RDP dejará de funcionar si está configurado en TLS. Así que me registré:

Admin Tools\Remote Desktop Services\Remote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer

y mi Nivel de seguridad se configuró en "Negociar". Supuse que esto significa que si TLS no está disponible, se degradaría con gracia a RDP Security.

Pero no, negociar no funciona de esa manera. Debe establecer el Nivel de seguridad en Seguridad RDP, no en Negociar, antes de deshabilitar TLS 1.0.

¡Así que perdí mi capacidad de conectarme remotamente a mi instancia de AWS!

Para volver a conectar, utilicé otra instancia de AWS.

  1. Actualicé el SecurityGroup para permitir la conexión de firewall desde esa máquina a mi máquina "perdida".
  2. Abrí un recurso compartido de red administrativa en DOS, con un usuario administrador y una contraseña:

net use \\lost_machine_ip\c$

  1. Luego abrí Regedit, y en el menú Archivo, seleccione "Conectar registro de red" e ingrese la IP del servidor "perdido". Debería ver el registro del servidor remoto. Ir :

\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp\

y establezca el valor SecurityLayeren 0 (0 es seguridad RDP).

Entonces podrá conectarse de forma remota y volver a habilitar TLS 1.0 en IISCrypto si es necesario.

Thierry_S
fuente
Gracias, esto me ahorró mucho trabajo recreando un servidor. No estoy seguro de cómo cambió su grupo de seguridad para permitir la conexión entre máquinas --- Abrí todo el acceso a la máquina "perdida" a la dirección IP de la segunda máquina, y funcionó. ¿Hay una mejor manera?
Gullbyrd
@Gullbyrd, ya sea eso, o establezca TODO TCP en el grupo de seguridad al que pertenecen ambas máquinas. Hace lo mismo.
Dave Beer
3

Deberá instalar RDP 8.0 en sus computadoras con Windows 7 y servidores Windows Server 2008 R2, y luego habilitar RDP 8.0 en la política de la computadora local o la política de grupo.

Aquí está el KB de Microsoft para el RDP 8.0. https://support.microsoft.com/en-us/kb/2592687

Una vez hecho esto, debería poder desactivar TLS 1.0 en las computadoras y servidores editando el registro como se indica en este artículo de technet. https://technet.microsoft.com/en-us/library/dn786418.aspx

Después de instalar RDP 8.0, también puede instalar RDP 8.1, pero RDP 8.0 debe instalarse antes de instalar RDP 8.1. RDP 8.0 contiene los componentes del protocolo del lado del cliente y del servidor, pero RDP 8.1 solo incluye al cliente. El KB de Microsoft para RDP 8.1 es KB2830477.

Realicé estos cambios en una de mis estaciones de trabajo con Windows 7 y probé las conexiones RDP con la configuración de directiva de grupo "Requerir el uso de una capa de seguridad específica para conexiones remotas (RDP)" habilitada y configurada en "SSL (TLS 1.0)" para asegurar que no recurriría al cifrado RDP.

ACTUALIZACIÓN 19/06/2015:

Finalmente tuve la oportunidad de probar esto en uno de nuestros servidores Windows Server 2008 R2, y definitivamente rompe las conexiones RDP al servidor. Parece que los componentes del lado del servidor RDP 8.0 solo se instalan en computadoras con Windows 7 y no se instalan en servidores Windows Server 2008 R2.

Kenny R
fuente
El artículo de la base de conocimiento de soporte al que se hace referencia no está funcionando actualmente (bucle de redireccionamiento), sin embargo, puede usar la versión de caché de Google para ver el contenido. Es interesante que todavía no se mencione absolutamente el soporte TLS 1.1 o 1.2 en este artículo y, sin embargo, ¡supongo que esa es la razón principal por la que alguien analizará esta pregunta! También hay una gran cantidad de advertencias, incluidos los administradores locales que ya no pueden iniciar sesión a menos que se agregue específicamente al grupo de usuarios de Remote Destop. Ten cuidado si estás intentando esto.
CarlR
¿Abrió el puerto UDP 3389 en el servidor cuando intentó conectarse al servidor 2008?
Elvar
Llegué a deshabilitar temporalmente el Firewall de Windows por completo en el servidor del servidor 2008 R2, pero aún no podía conectarme a él usando RDP con TLS 1.0 deshabilitado en el servidor.
Kenny R
3

Como se publicó en Cómo deshabilitar TLS 1.0 sin romper RemoteApps en el servidor 2012 R2, pero volver a publicar aquí en beneficio de aquellos que pueden no estar monitoreando ese enlace:

Después de casi un año, finalmente descubrí una solución de trabajo para deshabilitar TLS 1.0 / 1.1 sin interrumpir la conectividad RDP y Remote Desktop Services e iniciar RemoteApps:

Ejecute IISCrypto y desactive TLS 1.0, TLS 1.1 y todos los cifrados incorrectos.

En el servidor de Servicios de escritorio remoto que ejecuta la función de puerta de enlace, abra la Política de seguridad local y vaya a Opciones de seguridad - Criptografía del sistema: use algoritmos que cumplan con FIPS para el cifrado, el hash y la firma. Cambie la configuración de seguridad a Activado. Reinicie para que los cambios surtan efecto.

Tenga en cuenta que, en algunos casos (especialmente si se utilizan certificados autofirmados en Server 2012 R2), la opción de Política de seguridad Seguridad de red: el nivel de autenticación de LAN Manager puede necesitar configurarse para Enviar solo respuestas NTLMv2.

cardiotorácica
fuente
2

Solo una actualización de esto si alguien más está buscando información al respecto. Para mis cajas de Windows 7 de 64 bits tuve que instalar KB2574819 (primero) y KB2592687 (segundo) Windows 7 debe tener instalado SP1 antes de que se instalen esos 2 paquetes. Si tiene problemas para instalar SP1 como lo hice yo, primero tuve que desinstalar KB958830, luego instalar SP1.

Para mis cajas de Windows Server 2008 R2, tuve que instalar KB3080079. Una vez que haga esto y tenga todas las configuraciones apropiadas para una comunicación segura, entonces usará TLS 1.2. Puede confirmar usando Wireshark para realizar una captura de la comunicación entre sus dos cajas.

Seth Dunn
fuente
0

Un caso no cubierto por las respuestas existentes: los clientes de Windows 7 que se conectan a través de una puerta de enlace RDP seguirán utilizando TLS 1.0 al conectarse a la puerta de enlace y fallarán si la puerta de enlace no es compatible con TLS 1.0, incluso después de aplicar KB3080079 , como se observa en este hilo del foro de TechNet .

Para usar TLS 1.2 para conectarse a través de una puerta de enlace RDP, asegúrese de que KB3140245 esté instalado y agregue las siguientes claves de registro (guarde en un archivo con .regextensión para importar):

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp]
"DefaultSecureProtocols"=dword:00000800

Como se documenta en KB3140245 , esto anulará el WINHTTP_OPTION_SECURE_PROTOCOLSuso de TLS 1.2 (y solo TLS 1.2) de forma predeterminada. Tenga en cuenta que afectará más que solo al cliente RDP.

(Nota: si se desea compatibilidad con versiones anteriores, dword:00000800se puede cambiar a TLS 1.1 y 1.0 dword:00000A00o dword:00000A80incluirlo respectivamente)

Kevinoid
fuente