¿Cómo deshabilito TLS 1.0 sin romper RDP?

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 .

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

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

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.

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

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$

3. 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.

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.

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.

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.

He utilizado con éxito rdesktop ( http://www.rdesktop.org ) para Linux para solucionar este problema.

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)