Por que o Windows 7/2008 mstsc solicita a senha do nome de usuário ANTES do aviso do certificado do servidor?

Question

Ao usar o mstsc do Windows 7 para se conectar a um Windows Server 2008 (área de trabalho remota), noto um problema que não consigo explicar.

mstsc pede senha do nome de usuário primeiro. Se eu fornecer um errado, mstsc me diz "As credenciais que foram usadas para se conectar não funcionaram".

Somentedepoisdefornecerumcorreto,mstscmeavisaqueocertificadodoservidornãoéconfiável.

Eu acho que mstsc deve pedir "certificado de servidor não confiável" antes de verificar se o meu nome de usuário / senha é aceito pelo servidor ".

Então, minha pergunta é: é possível que, caso o servidor ao qual me conecto seja falso (hospedado por um invasor), minha credencial ficará comprometida?

Mesmo que minhas credenciais nunca sejam comprometidas em tal situação, não é melhor que o mstsc solicite um problema de certificado de servidor ANTES de pedir nome de usuário / senha? Pelo menos, isso poderia eliminar a preocupação de senha ser roubada para um usuário médio.

    

Answer 1

O que está acontecendo aqui é um pouco complexo, mas se você ler o NLA e o CredSSP, verá uma imagem melhor.

link

link

Basicamente, para responder à sua pergunta ... Não, um servidor falsificado não comprometeria suas credenciais. A primeira coisa que eles precisariam fazer para se enganar seria o spoof do DNS para um IP incorreto, mas mesmo assim o RDP funciona agora (assumindo que estamos falando de um cliente Win7 ou Vista e um servidor Win2008 ou mais novo) as credenciais são criptografado e não exposto (aviso é explicado pelo NTLM na parte inferior do artigo do Technet).

Veja um trecho que pode ajudar no artigo da Technet:

Unlike the experience in Windows Server® 2003 Terminal Server, the credential prompt is on the client computer and not the server. Most importantly, the client credential prompt is on the secure desktop. Therefore, not even the Terminal Services client can see the credentials, which is an important Common Criteria requirement. Furthermore, the credentials obtained from the prompt will not be delegated until the server identity is authenticated (subject to policy configuration). Finally, the terminal server will not establish a session for the user (which consumes a significant amount of memory and CPU processing time on the server) before authenticating the client, which decreases the chances of successful denial-of-service attacks on the server.

EDIT: vamos adicionar um exemplo para esclarecer ...

EXAMPLE #1 - USER HAS ACCESS TO REMOTE SERVER AND USES CORRECT PASSWORD

Neste exemplo, você digitará o nome de usuário e a senha, ele autenticará LOCALMENTE no domínio para verificar se é um nome de usuário / pwd válido e, em seguida, tentará se conectar ao servidor remoto. Nesse ponto, se for a primeira conexão, você provavelmente obterá a mensagem "A identidade do computador remoto não pode ser verificada" e você pode optar por confiar nela ou não.

EXAMPLE #2 - USER HAS ACCESS TO REMOTE SERVER AND USES INCORRECT PASSWORD

Aqui você verá a foto que você postou ... As credenciais não funcionaram. Por favor insira novas credenciais. Isso é feito localmente no cliente (validado contra um ticket do kerberos ou o DC) sem nunca se conectar ao servidor remoto.

EXAMPLE #3 - USER HAS NO ACCESS TO REMOTE SERVER BUT USES A CORRECT USERNAME AND PASSWORD

Aqui você autentica localmente, pois é uma conta válida e pwd, mas depois de se conectar ao servidor para passar as credenciais, você obterá:

Espero que ajude ...