Partilhar via

Visão geral da proteção estendida para autenticação

A Proteção Estendida para Autenticação ajuda a proteger contra ataques man-in-the-middle (MITM), nos quais um invasor interceta as credenciais de um 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 o URL https://server, enquanto o invasor tem o 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 ao 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, 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 ligação entre a chave de sessão gerada pelo Secure Sockets Layer (SSL) e a chave de sessão que é gerada durante a autenticação. Assim, no cenário anterior, se a comunicação ocorrer através de um TLS (como um canal HTTPS), há 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 detetar que o canal pelo 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 Channel Binding Token (CBT) para o servidor. O CBT é uma propriedade do canal externo protegido por TLS e é usado para vincular o canal externo a uma conversa pelo canal interno autenticado pelo cliente.

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

O lado do cliente não requer nenhuma definição de configuração. Uma vez que o cliente tenha sido atualizado para passar o CBT para o servidor, ele sempre faz isso. Se o servidor também tiver sido atualizado, ele pode ser configurado para usar o CBT ou ignorá-lo. Se não tiver sido atualizado, ignora-o.

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

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

  • Parcial. Todos os clientes que foram atualizados devem fornecer informações de vinculação de canal para o servidor. Os clientes que não foram atualizados não precisam fazê-lo. Esta é uma opção intermediária que permite a compatibilidade do aplicativo.

  • Completa. Todos os clientes devem fornecer informações de vinculaçã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 Win7 CBT/Extended Protection.

Ver também

  • Last updated on