A remoção da cifra vulnerável no Windows 10 interrompe o RDP de saída

O scanner de vulnerabilidades do TrustWave falha na verificação devido a uma máquina Windows 10 executando o RDP:

Algoritmos de criptografia de bloco com tamanho de bloco de 64 bits (como DES e 3DES), ataque de aniversário conhecido como Sweet32 (CVE-2016-2183)

NOTA: Nos sistemas Windows 7/10 que executam RDP (Protocolo de Área de Trabalho Remota), a cifra vulnerável que deve ser desativada é rotulada como 'TLS_RSA_WITH_3DES_EDE_CBC_SHA'.

Usando o IIS Crypto (da Nartac), tentei aplicar o modelo "Best Practices" e o modelo PCI 3.1, no entanto, ambos incluem a cifra insegura (TLS_RSA_WITH_3DES_EDE_CBC_SHA):

Se eu desativar esta cifra, RDP a partir deste computador para muitas estações do Windows pára de funcionar (ele ainda funciona até certo 2008 R2 e 2012 servidores R2). O cliente RDP simplesmente fornece "Ocorreu um erro interno" e o log de eventos:

Ocorreu um erro fatal ao criar uma credencial de cliente TLS. O estado do erro interno é 10013.

Eu verifiquei o log de eventos do servidor de um dos servidores e vi essas duas mensagens

Uma solicitação de conexão TLS 1.2 foi recebida de um aplicativo cliente remoto, mas nenhum dos conjuntos de cifras suportados pelo aplicativo cliente é suportado pelo servidor. A solicitação de conexão SSL falhou.

O seguinte alerta fatal foi gerado: 40. O estado do erro interno é 1205.

Como posso corrigir a vulnerabilidade de segurança sem interromper o RDP de saída?

Ou, se o exposto acima, não for possível, há algo que eu possa fazer em cada host RDP ao qual não posso mais me conectar e que lide com isso nesse sentido?

--- Atualização # 1 ---

Depois de desativar o TLS_RSA_WITH_3DES_EDE_CBC_SHA na máquina Windows 10, tentei conectar-me a vários hosts RDP (metade deles falhou com "Um erro interno ..."). Portanto, comparei um desses hosts aos quais posso conectar-me a outro que não consigo conectar. Ambos são 2008 R2. Ambos têm a mesma versão RDP (6.3.9600, protocolo RDP 8.1 suportado).

Comparei os protocolos e cifras TLS usando o IIS Crypto para fazer "Salvar modelo" em suas configurações atuais, para que eu pudesse comparar os arquivos de modelo. Eles eram idênticos! Portanto, qualquer que seja o problema, não parece ser uma falta de um pacote de chipher no host. Aqui está uma captura de tela do Beyond Compare nos arquivos:

O que poderia ser diferente entre os dois hosts RDP que causam esse problema e como corrigi-lo?

O IIS Crypto tem a opção de definir as opções do servidor (de entrada) e do cliente (de saída). Existem algumas cifras que você precisa deixar ativadas no lado do cliente para compatibilidade.

Para fazer o que você quer, eu pessoalmente diria o seguinte:

• Aplicar modelo 3.1
• Deixe todos os conjuntos de criptografia ativados
• Aplique ao cliente e ao servidor (caixa de seleção marcada).
• Clique em 'aplicar' para salvar as alterações

Reinicie aqui, se desejar (e você tem acesso físico à máquina).

• Aplicar modelo 3.1
• Deixe todos os conjuntos de criptografia ativados
• Aplicar ao servidor (caixa de seleção desmarcada).
• Desmarque a opção 3DES

A reinicialização aqui deve resultar no estado final correto.

Efetivamente, você deseja apenas desativar a entrada 3DES, mas ainda permitir o uso de saída do referido conjunto de cifras.

Eu tive o mesmo problema, a instalação do patch KB3080079 no servidor permite o suporte para tls 1.1 e 1.2.

Observe que, para clientes do Windows 7, será necessário instalar a atualização do cliente rdp (KB2830477); caso contrário, apenas o Windows 8+ poderá se conectar.

Edit (2018-09-26): Descobri que desabilitar o 3DES no 2012R2 NÃO quebra o RDP, mas quebra no 2008 R2. As opções suportadas parecem ser diferentes entre os kernels.

Compartilharei minha resposta de um tópico do TechNet, mas primeiro o BLUF:

Conclusão de falha do servidor: Muito provavelmente você tem alguma outra diferença entre os sistemas. Você está se conectando entre diferentes versões do sistema operacional, um sistema tem o FIPS ativado e o outro não, ou existem diferentes restrições de cifra em HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers. Eu certamente permitir o registo SCHANNEL no sistema que faz o trabalho para determinar qual cifra está em uso. Gostaria de receber uma resposta se de alguma forma você conseguiu que o RDP trabalhasse com uma cifra alternativa.

Cópia da postagem:

Temos que trabalhar!

Aparentemente, 2008 e 2012 têm problemas de sintaxe e o 2008/7 exige um / 168 à direita. 2012 / 8.1 / 10 não.

a chave em 2008 é assim: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168/168

E a chave em 2012 é assim: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\Triple DES 168

Posso confirmar que o uso do "Triple DES 168/168" NÃO desativa o 3DES no sistema. Você pode provar isso por si mesmo com um scanner de protocolo (como o Nessus) ou ativando o log do SCHANNEL:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL] "EventLogging"=dword:00000007

Você terá eventos no log do sistema, por exemplo;

Um handshake de cliente SSL foi concluído com êxito. Os parâmetros criptográficos negociados são os seguintes.

Protocolo: TLS 1.0 CipherSuite: 0x2f Força do Exchange: 1024

Para mim, o resultado é 0xa, que o Google revela como TLS_RSA_WITH_3DES_EDE_CBC_SHA.

Quando eu uso "Triple DES 168" (sem o / 168), a identificação de evento do sistema 36880 não aparece e a sessão RDP é bloqueada.

Por artigo: Criptografia do sistema: use algoritmos compatíveis com FIPS para criptografia, hash e assinatura

Serviços de área de trabalho remota (RDS) Para criptografar a comunicação de rede dos Serviços de Área de Trabalho Remota, essa configuração de diretiva oferece suporte apenas ao algoritmo de criptografia Triple DES.

Por artigo: "Criptografia do sistema: use algoritmos compatíveis com FIPS para criptografia, hash e assinatura" efeitos das configurações de segurança no Windows XP e em versões posteriores do Windows

Essa configuração também afeta os serviços de terminal no Windows Server 2003 e em versões posteriores do Windows. O efeito depende se o TLS está sendo usado para autenticação do servidor.

Se o TLS estiver sendo usado para autenticação do servidor, essa configuração fará com que apenas o TLS 1.0 seja usado.

Por padrão, se o TLS não estiver sendo usado, e essa configuração não estiver ativada no cliente ou no servidor, o canal RDP (Remote Desktop Protocol) entre o servidor e o cliente será criptografado usando o algoritmo RC4 com 128 bits. comprimento da chave. Depois de habilitar essa configuração em um computador com Windows Server 2003, o seguinte é verdadeiro: O canal RDP é criptografado usando o algoritmo 3DES no modo CBC (Cipher Block Chaining) com um comprimento de chave de 168 bits. O algoritmo SHA-1 é usado para criar resumos de mensagens. Os clientes devem usar o programa cliente RDP 5.2 ou uma versão posterior para se conectar.

Portanto, ambos apoiam a ideia de que o RDP só pode utilizar o 3DES. No entanto, este artigo sugere que uma maior variedade de cifras esteja disponível: Validação FIPS 140

O conjunto de algoritmos criptográficos que um servidor RDP (Remote Desktop Protocol) usará terá como escopo: - CALG_RSA_KEYX - algoritmo de troca de chave pública RSA - CALG_3DES - algoritmo de criptografia DES triplo - CALG_AES_128 - AES de 128 bits - CALG_AES_256 - AES de 128 bits - CALG_AES_256 - AES de 256 bits - CALG_SHA1 - Algoritmo de hash SHA - CALG_SHA_256 - Algoritmo de hash SHA de 256 bits - CALG_SHA_384 - Algoritmo de hash SHA de 384 bits - CALG_SHA_512 - Algoritmo de hash SHA de 512 bits

Por fim, não está claro se o RDP pode suportar protocolos não 3DES quando o modo FIPS está ativado, mas as evidências sugerem que não.

Não vejo evidências de que o Server 2012 R2 funcione de maneira diferente do Server 2008 R2, no entanto, parece que o Server 2008 R2 foi baseado na conformidade com o FIPS 140-1 e o Server 2012 R2 segue o FIPS 140-2, portanto, é perfeitamente possível que o Server 2012 R2 suporte protocolos adicionais. Você observará os protocolos adicionais no link Validação FIPS 140 .

Concluindo: não acho que o Server 2008 R2 possa suportar RDP no modo FIPS com o 3DES desativado. Minha recomendação é verificar se o seu sistema atende às condições para um ataque SWEET32 (mais de 768 GB enviado em uma única sessão) e se desabilitar o 3DES vale a pena remover o recurso RDP. Existem outros utilitários para gerenciar servidores além do RDP, especialmente em um mundo onde a virtualização é altamente comum.

Aparentemente, 2008 e 2012 têm problemas de sintaxe e o 2008/7 exige um / 168 à direita. 2012 / 8.1 / 10 não.

a chave em 2008 se parece com: HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Control \ SecurityProviders \ SCHANNEL \ Ciphers \ Triple DES 168/168

** Ótima descoberta, eu tive exatamente o mesmo problema em alguns controladores de domínio do Windows 2008 R2, estranhamente meus servidores 2008R2 membros parecem ok ... e meus servidores 2012R2 funcionam bem também. Precisa quebrar a decomposição dos DCs mais antigos :)