Como desabilito o TLS 1.0 sem interromper o RDP?


48

Nosso processador de cartão de crédito notificou-nos recentemente que em 30 de junho de 2016 precisaremos desativar o TLS 1.0 para permanecer em conformidade com o PCI . Tentei ser proativo desativando o TLS 1.0 em nossa máquina com Windows Server 2008 R2, apenas para descobrir que, imediatamente após a reinicialização, não consegui conectar-me completamente a ela via RDP (Remote Desktop Protocol). Após algumas pesquisas, parece que o RDP suporta apenas TLS 1.0 (veja aqui ou aqui ), ou pelo menos não está claro como habilitar o RDP sobre TLS 1.1 ou TLS 1.2. Alguém sabe como desabilitar o TLS 1.0 no Windows Server 2008 R2 sem interromper o RDP? A Microsoft planeja suporte para RDP sobre TLS 1.1 ou TLS 1.2?

Nota: Parece haver uma maneira de fazê-lo, configurando o servidor para usar a Camada de Segurança RDP, mas isso desativa a Autenticação no Nível da Rede , que parece trocar um mal por outro.

ATUALIZAÇÃO 1 : A Microsoft já resolveu esse problema. Veja a resposta abaixo para a atualização relevante do servidor.

ATUALIZAÇÃO 2 : A Microsoft lançou um tutorial sobre o suporte ao SQL Server para PCI DSS 3.1 .


Peço desculpas a todos - as instruções que publiquei são válidas apenas para o Win8 / Server2012 / 2012R2 ... elas não funcionam no 2008R2 / Win7. Eu testei 2008R2 e não é o mesmo. Eu sinto Muito.
Ryan Ries

E observe que, em 2012, como mencionado anteriormente, a remoção do TLS 1.0 força o RDP a fazer o downgrade para a camada de segurança RDP.
Jim B

Fiz a mesma coisa e não consigo entrar no meu servidor (AWS). Você conseguiu descobrir uma maneira de entrar sem acesso físico?
Thomas Paine

1
De acordo com este artigo de suporte, a Microsoft recentemente corrigiu o SQL 2012 e 2014 para trabalhar com o TLS 1.1 e 1.2 support.microsoft.com/en-us/kb/3052404
CarlR

1
@CarlR esse artigo não parece mencionar especificamente o RDP'ing no servidor. De fato, parece específico da conectividade do banco de dados, pois menciona: "Esta atualização adiciona o suporte à versão 1.2 do protocolo TLS (Transport Layer Security) ao SQL Server 2014 e ao Driver ODBC da Microsoft para SQL Server".
K1DBLITZ

Respostas:


19

A Microsoft lançou o patch para este problema 15 de setembro de 2015

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


Muito obrigado. Após a instalação dessas atualizações, a tela tsconfig.msc não mostra nenhum sinal do TLS 1.1 ou TLS 1.2. Alguém conseguiu confirmar que você está se conectando ao servidor usando o RDP sobre TLS 1.2? Eu sei que podemos verificar desativando o protocolo TLS inicial no servidor. Mas, se não funcionar, você não poderá usar o RDP remotamente no servidor.
Nirlep 18/09/2015

É possível que, ao selecionar a opção "Negociar", ele comunique o nível mais alto possível, o que poderia ser o TLS 1.2
Nirlep

1
Você pode ativar o log do canal para ver qual versão está sendo usada. O link de como fazer isso é mostrado na minha resposta.
CarlR

Eu sei que é um thread antigo, mas ... Eu tenho um Windows Server 2008 R2 mais antigo que estou trazendo para o snuff. Instalei o KB3080079 e agora desativará o TLS 1.0. Mas não tenho certeza se a configuração do servidor RDP deve ser definida como "Negociar" ou "TLS".
22417 Chris Harrington

15

Estou analisando isso há alguns dias, pois precisamos cumprir o PCI-DSS 3.1, que exige que o TLS 1.0 seja desativado.

Também não queremos voltar à Camada de Segurança RDP, que é uma grande preocupação de segurança.

Finalmente consegui encontrar alguma documentação que confirme que o TLS 1.1 e o TLS 1.2 SÃO suportados pelo RDP. Esta documentação está oculta em um log do SChannel e em uma especificação muito detalhada para o RDP .

Existe uma completa falta de documentação sobre o fluxo principal no Technet ou em outros sites da Microsoft. Parece que documentar isso aqui aqui pode ajudar algumas pessoas.

Extratos relevantes dos links fornecidos:

No link MSDN:

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

No PDF de especificação do 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"

Portanto, pode-se concluir que você pode usar o TLS 1.1 ou 1.2 no Windows Server 2008 R2 de acordo com esta documentação.

No entanto, nossos testes provaram que isso NÃO funciona no cliente RDP do Windows 7 (versão 6.3.9600) quando o TLS 1.0 está desativado e a opção de segurança RDP está configurada para exigir o TLS 1.0.

Isso é claro, além de habilitar o TLS 1.1 e 1.2 que estão desativados por padrão em 2008R2 - aliás, fazemos isso usando a muito útil ferramenta de criptografia do IIS da Nartac Software .

Ao analisar esse problema, é útil habilitar o log do SChannel para ver mais detalhes do que está acontecendo quando a sessão é aberta.

Você pode definir o log do SChannel alterando a chave HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ EventLogging para 5 e reiniciando.

Uma vez feito isso, você poderá observar os eventos do SChannel, que mostram a versão do TLS sendo usada quando uma conexão RDP é estabelecida. Depois que o log estiver ativado, você poderá observar o erro SChannel quando o cliente RDP tentar estabelecer uma conexão no Windows 2008 R2 com o TLS 1.0 desativado:

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

Também testei a desativação do TLS 1.0 no Windows Server 2012 e 2012 R2, que posso confirmar que funciona perfeitamente usando o Windows 7 RDP Client. A entrada de log do SChannel mostra o TLS 1.2 sendo usado:

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

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

Espero que isso ajude alguém que está procurando esclarecimentos sobre isso.

Vou continuar procurando como o RDP pode funcionar com o TLS 1.1 e o TLS 1.2 no Windows Server 2008 R2.

ATUALIZAÇÃO: 2015-AGO-05

Levantamos a questão do RDP não funcionar com o Server 2008 R2 com suporte da Microsoft, incluindo as etapas de reprodução.

Após várias semanas de retrocesso e encaminhamento, finalmente recebemos um telefonema hoje da equipe de suporte para reconhecer que eles realmente poderiam reproduzi-lo e isso agora é classificado como um bug. Um patch de atualização será lançado, no momento previsto para outubro de 2015. Assim que tiver um artigo da KB ou outros detalhes, os adicionarei a esta postagem.

Esperamos que aqueles que estão presos ao Windows Server 2008 R2 possam pelo menos resolver isso antes do prazo final de junho de 2016, quando o patch for lançado.

ATUALIZAÇÃO: 19 de setembro de 2015

A Microsoft finalmente lançou um artigo de suporte em kb sobre isso aqui e posso confirmar que funciona bem.


Sua última atualização afirma: "Eu tentei o Windows 7 e o Windows 2012 R2 e ele não funciona; ele ainda se conecta usando o TLS1". Você já conseguiu fazer isso funcionar?
Doug S

Alguém colocou esse comentário, acabei de removê-lo, pois agora funciona bem para nós através do TLS1.2.
CarlR

Hummm. Nunca consegui fazê-lo funcionar, mesmo com essas alterações / atualizações e tudo o mais que pude encontrar.
Doug S

O log do SChannel pode ser encontrado no log do sistema.
Ivan Chau

8

Em vez disso, use IPsec, pois o documento recomenda: "Configurando uma sessão fortemente criptografada primeiro (por exemplo, túnel IPsec) e depois enviando dados por SSL dentro do túnel seguro"

O principal motivo para fazer isso ao configurar o TLS para RDP é que a política de firewall é facilmente auditada quanto à conformidade (contra a comprovação de que várias alterações no registro são compatíveis) e o IPsec é muito fácil de configurar no Windows.

Se você precisar de conformidade com o conjunto B completo, o IPSEC com tls 1.0 é a única maneira disponível para aplicar-se aos comprimentos de certificado apropriados


O tunelamento sobre SSH também é uma opção que mencionarei. (Requer o software servidor SSH para Windows, é claro.)
Chris W. Rea

O IPsec não é SSH
Jim B

3
Correto, e eu não quis dizer que eles são iguais. Em vez disso, o SSH é um método alternativo para estabelecer um túnel seguro para um servidor.
Chris W. Rea

@ JimB Sinto muito, você estava certo.
Ryan Ries

1
@RyanRies Np, ainda estou coçando a cabeça como outros 12 votariam sem saber que funcionava.
Jim B

8

Esta não é uma resposta para a pergunta, mas para a sub-pergunta "Como restauro o acesso remoto a uma máquina virtual em que desativei o TLS 1.0 e sem acesso físico?".

Desativei o TLS 1.0 usando o IISCrypto, que dava um aviso útil sobre o efeito colateral de que o RDP deixará de funcionar se estiver definido como TLS. Então eu fiz o check-in:

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

e meu nível de segurança foi definido como "Negociar". Supus que isso significa que, se o TLS não estiver disponível, ele seria degradado normalmente para o RDP Security.

Mas não, negociar não funciona dessa maneira. Você deve definir o Nível de segurança como Segurança RDP, não Negociar, antes de desabilitar o TLS 1.0.

Então, perdi minha capacidade de me conectar remotamente à minha instância da AWS!

Para reconectar, usei outra instância da AWS.

  1. Atualizei o SecurityGroup para permitir a conexão do firewall dessa máquina com a minha máquina "perdida".
  2. Abri um compartilhamento de rede administrativa no DOS, com um usuário e senha de administrador:

net use \\lost_machine_ip\c$

  1. Então eu abri o Regedit e, no menu Arquivo, escolha "Conectar registro de rede" e insira o IP do servidor "perdido". Você deve ver o registro do servidor remoto. Vamos para :

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

e defina o valor para SecurityLayer0 (0 é RDP Security).

Você poderá conectar-se remotamente e reativar o TLS 1.0 no IISCrypto, se necessário.


Obrigado, isso me salvou muito trabalho recriando um servidor. Não tenho certeza de como você alterou seu grupo de segurança para permitir a conexão entre máquinas --- eu abri todo o acesso à máquina "perdida" ao endereço IP da segunda máquina e funcionou. Existe uma maneira melhor?
Gullbyrd 27/01

@Gullbyrd ou defina ALL TCP para o grupo de segurança ao qual ambas as máquinas pertencem. Faz a mesma coisa.
Dave Beer

3

Você precisará instalar o RDP 8.0 nos computadores Windows 7 e nos servidores Windows Server 2008 R2 e habilitar o RDP 8.0 na diretiva do computador local ou na diretiva de grupo.

Aqui está o Microsoft KB para o RDP 8.0. https://support.microsoft.com/en-us/kb/2592687

Feito isso, você poderá desativar o TLS 1.0 nos computadores e servidores editando o registro conforme as instruções neste artigo técnico. https://technet.microsoft.com/en-us/library/dn786418.aspx

Depois de instalar o RDP 8.0, você também pode instalar o RDP 8.1, mas o RDP 8.0 deve ser instalado antes da instalação do RDP 8.1. O RDP 8.0 contém os componentes de protocolo do cliente e do servidor, mas o RDP 8.1 inclui apenas o cliente. O Microsoft KB para RDP 8.1 é KB2830477.

Fiz essas alterações em uma das minhas estações de trabalho Windows 7 e testei as conexões RDP com a configuração "Diretiva de grupo" Exigir uso de camada de segurança específica para conexões remotas (RDP) "" ativada e definida como "SSL (TLS 1.0)" para garantir que não voltaria à criptografia RDP.

ATUALIZAÇÃO 19/06/2015:

Finalmente tive a chance de testar isso em um de nossos servidores Windows Server 2008 R2 e, definitivamente, interrompe as conexões RDP com o servidor. Parece que os componentes do servidor RDP 8.0 estão instalados apenas nos computadores com Windows 7 e não são instalados nos servidores Windows Server 2008 R2.


O artigo da base de conhecimento de suporte mencionado não está funcionando no momento (loop de redirecionamento). No entanto, você pode usar a versão do cache do Google para ver o conteúdo. Interessante que ainda não haja nenhuma menção ao suporte ao TLS 1.1 ou 1.2 neste artigo e, no entanto, acho que esse é o principal motivo pelo qual alguém estará analisando essa questão! Também há um grande número de advertências, incluindo os administradores locais que não conseguem mais fazer login, a menos que sejam especificamente adicionados ao grupo de usuários do Remote Destop. Cuidado se você estiver tentando isso.
CarlR

Você abriu a porta UDP 3389 no servidor quando tentou se conectar ao servidor 2008?
Elvar

Fui até desabilitar temporariamente o Firewall do Windows completamente no servidor 2008 R2, mas ainda não consegui me conectar a ele usando o RDP com o TLS 1.0 desativado no servidor.
Kenny R

3

Conforme publicado em Como desativar o TLS 1.0 sem interromper o RemoteApps no servidor 2012 R2, mas também republicando aqui para o benefício daqueles que podem não estar monitorando esse link:

Depois de quase um ano, finalmente descobri uma solução funcional para desativar o TLS 1.0 / 1.1 sem interromper a conectividade RDP e Serviços de Área de Trabalho Remota e iniciar o RemoteApps:

Execute o IISCrypto e desative o TLS 1.0, TLS 1.1 e todas as cifras incorretas.

No servidor dos Serviços de Área de Trabalho Remota executando a função de gateway, abra a Diretiva de Segurança Local e navegue até Opções de Segurança - Criptografia do sistema: use algoritmos compatíveis com FIPS para criptografia, hash e assinatura. Altere a configuração de segurança para Ativado. Reinicie para que as alterações entrem em vigor.

Observe que em alguns casos (especialmente se estiver usando certificados autoassinados no Server 2012 R2), a opção Política de segurança Segurança da rede: nível de autenticação do LAN Manager pode precisar ser configurada para Enviar apenas respostas NTLMv2.


2

Apenas uma atualização sobre isso, se mais alguém estiver procurando informações. Nas minhas caixas de 64 bits do Windows 7, tive que instalar o KB2574819 (primeiro) e o KB2592687 (segundo) o Windows 7 deve ter o SP1 instalado antes da instalação desses 2 pacotes. Se você tiver problemas para instalar o SP1 como eu, tive que desinstalar o KB958830 primeiro e instalar o SP1.

Nas caixas do Windows Server 2008 R2, tive que instalar o KB3080079. Depois de fazer isso e com todas as configurações apropriadas para a comunicação segura, o TLS 1.2 será usado. Você pode confirmar usando o Wireshark para capturar a comunicação entre as duas caixas.



0

Um caso não coberto pelas respostas existentes: os clientes Windows 7 que se conectam por meio de um gateway RDP ainda usarão o TLS 1.0 ao se conectar ao gateway e falharão se o gateway não suportar o TLS 1.0, mesmo após a aplicação do KB3080079 , conforme observado neste thread do fórum do TechNet .

Para usar o TLS 1.2 para conectar-se através de um gateway RDP, verifique se o KB3140245 está instalado e adicione as seguintes chaves do Registro (salve em um arquivo com .regextensão a ser importada):

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

Conforme documentado no KB3140245 , isso substituirá o WINHTTP_OPTION_SECURE_PROTOCOLSuso do TLS 1.2 (e somente TLS 1.2) por padrão. Esteja ciente de que isso afetará mais do que apenas o cliente RDP.

(Nota: Se a compatibilidade com versões anteriores for desejada, dword:00000800pode ser alterado para dword:00000A00ou dword:00000A80para incluir TLS 1.1 e 1.0, respectivamente)

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.