Compartilhar via


Proteção estendida para visão geral de autenticação

A Proteção Estendida para Autenticação ajuda a proteger contra ataques intermediários (MITM), nos quais um invasor intercepta as credenciais do cliente e as encaminha para um servidor.

Considere um cenário com três participantes: um cliente, um servidor e um invasor. O servidor tem a URL https://server, enquanto o invasor tem a URL https://attacker. O invasor engana o cliente para acessar o invasor como se fosse o servidor. Em seguida, o invasor envia uma solicitação para o servidor. Se o invasor estiver tentando acessar um recurso seguro, o servidor responderá ao invasor com um cabeçalho WWW-Authenticate. O invasor não tem as informações de autenticação, portanto, ele envia o cabeçalho WWW-Authenticate para o cliente. O cliente envia o cabeçalho de Autorização para o invasor e o invasor envia o cabeçalho para o servidor e obtém acesso aos recursos seguros usando as credenciais do cliente.

Atualmente, quando um aplicativo cliente se autentica no servidor usando Kerberos, Digest ou NTLM usando HTTPS, um canal TLS (Transport Level Security) é estabelecido pela primeira vez e a autenticação ocorre usando esse canal. No entanto, não há nenhuma associação entre a chave de sessão gerada pelo SSL (Secure Sockets Layer) e a chave de sessão gerada durante a autenticação. Portanto, no cenário anterior, se a comunicação ocorrer em um TLS (como um canal HTTPS), haverá dois canais SSL criados: um entre o cliente e o invasor e outro entre o invasor e o servidor. As credenciais do cliente são enviadas do cliente para o servidor primeiro pelo canal SSL entre o cliente e o invasor e, em seguida, pelo canal entre o invasor e o servidor. Depois que as credenciais do cliente chegam ao servidor, o servidor verifica as credenciais sem detectar que o canal sobre o qual essas credenciais foram enviadas se originou com o invasor e não com o cliente.

A solução é usar um canal externo protegido por TLS e um canal interno autenticado pelo cliente e passar um CBT (Token de Associação de Canal) para o servidor. O CBT é uma propriedade do canal externo protegido por TLS e é usado para associar o canal externo a uma conversa pelo canal interno autenticado pelo cliente.

No cenário anterior, o CBT do canal TLS do invasor de cliente é mesclado com as informações de autorização que são enviadas ao servidor. Um servidor com reconhecimento CBT compara o CBT contido nas informações de autenticação do cliente, que correspondem ao canal cliente-invasor, ao CBT anexado ao canal invasor-servidor. Um CBT é específico para o destino de um canal, portanto, o CBT do invasor do cliente não corresponde ao CBT do servidor invasor. Isso permite que o servidor detecte o ataque MITM e recuse a solicitação de autenticação.

O lado do cliente não requer nenhuma configuração. Depois que o cliente for atualizado para passar o CBT para o servidor, ele sempre o fará. Se o servidor também tiver sido atualizado, ele poderá ser configurado para usar o CBT ou ignorá-lo. Se não tiver sido atualizado, ele o ignorará.

O servidor pode ter os seguintes níveis de proteção:

  • Nenhum. Nenhuma validação de associação de canal é executada. Esse é o comportamento de todos os servidores que não foram atualizados.

  • Parcial. Todos os clientes que foram atualizados devem fornecer informações de associação de canal ao servidor. Os clientes que não foram atualizados não precisam fazer isso. Essa é uma opção intermediária que permite a compatibilidade do aplicativo.

  • Completa. Todos os clientes devem fornecer informações de associação de canal. O servidor rejeita solicitações de autenticação de clientes que não o fazem.

Para obter mais informações, consulte o exemplo de Proteção Estendida/CBT do Win7.

Confira também