Proteção MITM leve e simples para HTTP?

Question

PARA ESTAR CLARO: NÃO estou querendo escrever meu próprio protocolo ou minha própria implementação no lado do cliente. Eu estou procurando um protocolo EXISTING, parte dos padrões HTTP, que geralmente é suportado por navegadores comuns. (Tal coisa pode não existir.)

Eu tenho um aplicativo HTTP que precisa de alguma proteção contra ameaças man-in-the-middle. (O servidor precisa ser capaz de provar a autenticidade de suas respostas ao cliente.) A criptografia é irrelevante e desnecessária. Além disso, o orçamento de hardware é muito pequeno, considerando a taxa de acertos esperada.

Normalmente, eu acabei de obter um certificado barato e ativar o SSL no servidor da Web, mas um gerador de carga eliminou o Apache e o Nginx (e não espero que nenhum outro servidor da Web funcione melhor). Para serviços não HTTP, a carga está bem. Eu também tentei configurar o servidor HTTPS para negociar uma criptografia de criptografia nula. Isso ajudou um pouco, mas o handshake SSL ainda é muito pesado.

Uma simples assinatura SHA-1 (gerada pelo servidor) sobre o documento de resposta, verificada pelo cliente, serviria muito bem para mim. Eu escrevi um script Python FastCGI simples e um cliente HTTP para testar apenas a operação SHA-1 nua - ele adiciona um pouco de carga, mas não muito, nem perto do que o SSL com criptografia nula adiciona. Na prática, porém, meus clientes não serão scripts Python, eles serão navegadores da Web.

(DE NOVO, PARA SER LIMPA: Eu não estou propondo meu próprio protocolo de criptografia, o script Python foi apenas um teste de quanto carga o hash SHA-1 gera, por si só, versus o restante da negociação SSL. não posso usar uma implementação customizada do lado do cliente, porque não tenho como instalá-la para todos os navegadores clientes.)

Portanto: Existe algum protocolo de autenticação de servidor EXISTING leve (comparado a SSL) para HTTP?

    

Answer 1

O que você procura realmente não existe. O mecanismo leve embutido nos navegadores e servidores é SSL.

    

Answer 2

Se você está injetando um SHA1 em seu conteúdo, e eu estou MITMing você, o que me impede de consertar o SHA1 também?

    

Answer 3

Algumas soluções alternativas incluem:

• HTTP Digest para nomes de usuário / senhas
• DNSSEC para validação de endereço de servidor

• faz o mecanismo de handshake do ajax e a validação da página do HMAC. Se você inserir a página imitando o mecanismo de chave pública / privada - terceiros podem facilmente interferir nos dados, senão o MITM também pode corrigir facilmente o hash de dados. Lembre-se de que a criptografia raramente é feita da maneira correta, então fique de pé sobre os ombros dos outros e use mecanismos comprovados.

  Eu sugiro que você use ssl, com o nginx ajustado (veja sessões e cifras ssl). Caso contrário, seu MITM será apenas paródia e desperdício de trabalho e ciclos de cpu.

Answer 4

Dependendo de quanto controle você tem sobre o cliente, você pode substituir o SHA1 trivialmente viável por HMACSHA1 . O problema com os HMACs é que eles exigem que uma chave secreta seja conhecida nos dois lados da transmissão de antemão. Qualquer pessoa com acesso ao seu cliente provavelmente seria capaz de extrair a chave secreta desmontando-a.

Usamos isso antes para casos em que tivemos dois servidores da web separados, um que forneceu o site, e um que processou pedidos, que estavam localizados em datacenters geograficamente distintos. Isso garantiu que ninguém seria capaz de enviar solicitações diretamente para o servidor de atendimento e cobrar das pessoas.

    

Answer 5

O problema com o uso de um protocolo obscuro ou sob medida para assinatura é que ele não está embutido no (s) navegador (es). Isso significa que você precisa fornecer a lógica de validação ao navegador remoto. Se você não tiver proteção contra um ataque MITM ao entregar esse código / lógica, o que impede o MITM de apenas substituir o código de validação por algo que retorne "VALID", não importa o que ele veja - e / ou, o que interrompe o MITM de extrair o segredo compartilhado usado para o HMAC do código de validação do lado do cliente e usando isso no ataque MITM?

Se você simplesmente não puder fazer criptografia SSL em tempo real, poderá reorganizar seu processo para usar o HTTP para fornecer respostas pré-calculadas que foram assinadas por GPG ou assinadas off-line como parte de um processo em lote? Se você precisar incluir dados do usuário no cálculo / determinação da resposta, você poderá adicionar solicitações a uma fila processada em lote, com resultados assinados por GPG entregues posteriormente por meio de uma seção de resposta de um usuário em HTML e / ou via E-mail. ?

Você precisa que isso esteja disponível 24x7x365 ou é usado esporadicamente? (por exemplo, eventos de tipo de registro em que você tem muita carga em um dia ou semana, e nada durante meses) Se for o último, você poderia usar um servidor baseado em nuvem que você acabou de alugar por um dia ou uma semana e depois girar até que você precise novamente?

    

Answer 6

Em vez de tentar resolver o problema errado, pegue um cartão de aceleração de criptografia ou coloque o Nginx na frente do seu servidor da web em uma configuração acelerador SSL / proxy reverso e ser feito com isso.