Solución:
Solución 1:
Microsoft lanzó el parche para este problema el 15 de septiembre de 2015
Consulte https://support.microsoft.com/en-us/kb/3080079
Solucion 2:
He estado investigando esto durante un par de días, ya que debemos cumplir con PCI-DSS 3.1, que requiere que TLS 1.0 esté deshabilitado.
Tampoco queremos volver a la capa de seguridad RDP, que es un problema de seguridad importante.
Finalmente logré encontrar alguna documentación que confirme que TLS 1.1 y TLS 1.2 SON compatibles con RDP. Esta documentación está oculta en un registro de SChannel y una especificación muy detallada para RDP.
Parece que hay una falta total de documentación de flujo principal en Technet u otros sitios de Microsoft, por lo que es de esperar 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 especificaciones de 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.
Por supuesto, esto es además de habilitar TLS 1.1 y 1.2, que están desactivados de forma predeterminada en 2008R2; por cierto, lo hacemos utilizando la muy útil herramienta criptográfica 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 configurar 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 los eventos de SChannel que muestran la versión de TLS que se usa 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, lo que puedo confirmar que funciona perfectamente con el cliente RDP de Windows 7. La entrada de registro de 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 una aclaración sobre esto.
Continuaré 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-AUG-05
Planteamos el problema de que RDP no funciona con Server 2008 R2 con el soporte de Microsoft, incluidos los pasos para reproducir.
Después de varias semanas de retrocesos y reenvíos, finalmente recibimos una llamada telefónica hoy del equipo de soporte para reconocer que, de hecho, podrían reproducirlo y esto ahora se clasifica como un error. Se lanzará un parche de actualización, por el 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.
Es de esperar que aquellos atascados con Windows Server 2008 R2 al menos puedan 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 de kb sobre esto aquí y puedo confirmar que funciona bien.
Solución 3:
En su lugar, utilice IPsec, como recomienda el documento: “Primero, configure una sesión fuertemente encriptada (por ejemplo, un túnel IPsec) y luego envíe 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 verificar el cumplimiento (en lugar de demostrar que una gran cantidad de cambios en el registro cumplen) e IPsec es bastante fácil de configurar en Windows.
Si necesita el cumplimiento de la suite B completa, IPSEC con tls 1.0 es la única forma disponible para aplicar a las longitudes de certificado adecuadas
Solución 4:
Esta no es una respuesta a la pregunta, sino a la subpregunta “¿Cómo restauro el acceso remoto a una máquina virtual en la que 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 ToolsRemote Desktop ServicesRemote Desktop Session Host Configuration, RDP-Tcp, General Tab, Security Layer
y mi nivel de seguridad se estableció en “Negociar”. Supuse que esto significa que si TLS no está disponible, se degradaría graciosamente a RDP Security.
Pero no, Negotiate no funciona de esa manera. Debe establecer el Nivel de seguridad en Seguridad RDP, no Negociar, antes de deshabilitar TLS 1.0.
¡Así que perdí la capacidad de conectarme de forma remota a mi instancia de AWS!
Para volver a conectar, utilicé otra instancia de AWS.
- Actualicé SecurityGroup para permitir la conexión de firewall desde esa máquina a mi máquina “perdida”.
- Abrí un recurso compartido de red administrativa en DOS, con un usuario administrador y una contraseña:
net use \lost_machine_ipc$
- Luego abrí Regedit, y en el menú Archivo, elijo “Conectar registro de red” y puse la IP del servidor “perdido”. Debería ver el registro del servidor remoto. Ir a :
SYSTEMCurrentControlSetControlTerminal ServerWinStationsRDP-Tcp
y establezca el valor para SecurityLayer a 0 (0 es seguridad RDP).
Luego podrá conectarse remotamente y volver a habilitar TLS 1.0 en IISCrypto si es necesario.
Solución 5:
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 equipo local o la política de grupo.
Aquí está la base de conocimiento de Microsoft para RDP 8.0. https://support.microsoft.com/en-us/kb/2592687
Una vez hecho esto, debería poder deshabilitar 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 de 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.
Hice 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 garantizar 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 de RDP 8.0 solo se instalan en computadoras con Windows 7 y no se instalan en los servidores de Windows Server 2008 R2.