SSL: "segurança ponto a ponto" vs "segurança fim a fim"?

Question

Eu li que o SSL é uma boa solução para segurança "ponto a ponto", e não segurança "fim a fim". Por exemplo, em este artigo na JavaWorld, diz:

SSL/TLS is simply not designed for such a scenario; SSL/TLS only handles point-to-point security... SSL/TLS may secure the path between any two [intermediaries], but not from one end to the other.

Estou criando um serviço da Web para fornecer dados a clientes separados, conforme descrito em esta questão de Programmers.SE . Meu entendimento da implementação do SSL nesse contexto é que eu poderia adicionar algum tipo de chave de API a todas as minhas chamadas de serviço da Web e forçar o HTTPS somente no serviço, e estou tão seguro quanto preciso estar (não estou passando qualquer coisa específica do usuário, que não seja um endereço de e-mail sob certas circunstâncias, que sejam claras e iniciadas pelo usuário). Mas esta declaração e este artigo parece estar contestando isso. Está sugerindo que um ataque man-in-the-middle ainda é possível em uma conexão SSL? O guia OAuth declara aqui (segundo parágrafo em "Além" básico ") que:

HTTPS is the recommended solution to prevent a man-in-the-middle attack (MITM), eavesdropping, and other security risks.

Como isso é reconciliado?

    

Answer 1

Vá ler o artigo novamente.

O que ele está falando é a retransmissão de dados - nesse cenário, o cliente fala com seu servidor (por SSL), seu servidor fala sobre outro serviço por SSL. Enquanto a informação enviada do cliente é destinada ao outro serviço, este modelo requer que o seu servidor tenha visibilidade - você é o homem do meio por design nesta arquitetura. O cliente não vê as credenciais do outro servidor. Ambas as conexões são seguras.

Este artigo é sobre tunelamento de dados para um site remoto, mantendo uma relação de confiança entre o cliente e o 'outro servidor' - mas, no final, se o outro servidor enviar esses dados para outro lugar, a integridade do sistema falhará. falhará se você não usar SSL em nenhuma das duas conexões no modelo de três nós.

    

Answer 2

Você não pode se proteger totalmente contra todos os cenários, e o SSL pode ser comprometido por um ataque man-in-the-middle. Às vezes o MITM é executado propositalmente, digamos que você esteja usando um gateway de conteúdo da Websense ou um firewall Palo Alto que oferece descriptografia SSL on the fly. Nesse cenário, o cliente confia em uma CA ou CA intermediária que está emitindo certificados dinamicamente para descriptografar e criptografar novamente os dados de maneira transparente.

SSL, como muitas outras tecnologias, é mais sobre confidencialidade e faz um bom trabalho. Agora, o MITM pode ser usado para manipular o conteúdo, o que seria mais importante na integridade dos dados.

Eu acho que o que estou dizendo é que o SSL é bem testado e verdadeiro. Obtenha um certificado de uma autoridade de certificação bem conhecida e você ficará bem, mas não poderá controlar se o cliente foi comprometido.