Quais técnicas são recomendadas para evitar um ataque MITM ao usar pares de chaves pública / privada (RSA)?

1

Atualmente, tenho um grupo de interfaces de exposição de serviços da Web para vários tipos e funções diferentes de clientes. A autenticação é tratada por meio de pares de chaves pública / privada (RSA) apenas para verificar a URL como assinatura no cabeçalho HTTP.

Neste momento o Corpo HTTP não é criptografado (eu uso uma chave privada / pública de 2048 bits que me permite criptografar apenas pequenas quantidades de informação), então o RSA não é seguro o suficiente porque o servidor não pode mais provar para si mesmo que não há um homem no meio. Eu posso criptografar também o corpo HTTP, mas o que acontece com o desempenho?

Minha pergunta é: quais técnicas são recomendadas para evitar um ataque MITM neste caso?

    
por user65567 25.02.2011 / 17:17

3 respostas

2

Não há absolutamente nenhum ponto no uso de HTTPS se você não criptografar toda a sessão autenticada. Se algum ponto transmitir o ID da sessão por um canal inseguro, um invasor poderá usá-lo para autenticar (como o Firesheep). Ainda mais, você está violando OWASP a9 .

De uma perspectiva de desempenho, a parte mais cara do SSL é o aperto de mão inicial. Isso é armazenado em cache e é feito apenas uma vez por cliente.

Outra coisa a ter em mente é que, se você quiser parar os ataques de SSLStrip , defina o < a href="http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security"> STS-Header .

    
por 25.02.2011 / 17:50
2

Se sua meta for somente autenticidade (e não confidencialidade), a assinatura no cabeçalho, seja do cliente ou do servidor, ou em ambas as direções, pode ser usada para verificar se os bits recebidos são do remetente.

Observe que, se o conteúdo assinado não tiver um registro de data e hora que esteja marcado, ele estará vulnerável a uma reprodução simples, o que poderia permitir que alguém no meio realizasse alguma função ou se mascarasse como o outro lado indefinidamente.

O erro "dados muito grandes para o tamanho da chave" ocorre parcialmente porque a criptografia / descriptografia RSA direta é computacionalmente intensa, portanto, a implementação não é projetada para processar grandes quantidades de dados. O limite real está relacionado às garantias de força criptográfica fornecidas pelo algoritmo. Permitir que uma carga útil grande e de baixa entropia enfraquecesse.

Para evitar esse erro, é necessário usar um algoritmo de resumo de mensagem que executa um hash unidirecional como o MD5 em um conjunto maior de bits, como o corpo HTTP POST, e criptografar o resultado do digest de tamanho fixo usando criptografia RSA . O hash criptografado é essencialmente uma assinatura digital. O receptor então descriptografa, calcula o resultado do hash do corpo e compara os hashes para verificar a assinatura.

Observe que, se uma chave de sessão estiver disponível porque a criptografia também está sendo usada, o hash do corpo pode ser simplesmente criptografado com essa chave simétrica compartilhada, em vez de fazer a criptografia RSA mais cara. Isso é chamado de código de autenticação de mensagem (MAC) e não é tão strong quanto uma assinatura.

    
por 22.11.2012 / 02:59
1

Escolha uma solução testada e comprovada: use HTTPS com autenticação mútua, como um bônus que criptografa toda a sessão. O desempenho de HTTPS não é um problema, a menos que seu cliente esteja executando na calculadora de TI. Google usando para todo o Gmail, este deve ser um bom exemplo.

    
por 25.02.2011 / 18:22