Apache: Validar cadeia de confiança SSL para evitar ataques MITM?

Question

Acabei de perceber que os ataques SSL man-in-the-middle são muito mais comuns do que eu pensava, especialmente em ambientes corporativos. Já ouvi falar e vi várias empresas que possuem um servidor proxy SSL transparente. Todos os clientes estão configurados para confiar no certificado deste proxy. Isso basicamente significa que o empregador, teoricamente, pode interceptar até mesmo o tráfego criptografado por SSL sem qualquer aviso no navegador. Como mencionado acima, os clientes vêm com o certificado sendo confiável. Isso só pode ser revelado validando manualmente o certificado que está sendo usado.

Para mim, parece que o empregador utiliza sua posição superior para espionar o tráfego SSL do funcionário. Para mim, isso torna todo o conceito de SSL indigno de confiança. Eu testei com sucesso uma configuração semelhante usando mitmproxy e consegui ler a comunicação entre o cliente e meu servidor bancário eletrônico. Esta é uma informação que não deve ser revelada a ninguém.

Assim, minha pergunta é bastante simples: Como posso validar a cadeia de confiança no lado do servidor? Eu quero ter certeza de que o cliente usa o certificado do meu servidor e apenas uma cadeia de confiança. Gostaria de saber se isso pode ser conseguido pela configuração SSL do Apache? Isso seria conveniente, pois poderia ser aplicado a muitos aplicativos facilmente. Se isso não for possível, alguém sabe de uma maneira de fazer isso em PHP? Ou você tem alguma outra sugestão?

    

Answer 1

Eu acho que essa pergunta seria mais apropriada para security.stackexchange.com onde o tópico do MITM é discutido em muitas questões. Mas de qualquer maneira:

A validação do certificado do servidor é feita apenas no cliente e não pode ser movida de alguma forma para o servidor, pois o ponto de validação do certificado no cliente é que os clientes precisam ter certeza de que estão falando com o servidor correto e não pode confiar no servidor (não confiável) para tomar essa decisão pelo cliente.

No caso de interceptação SSL, o cliente TLS, na perspectiva do servidor, é o firewall de interceptação SSL / AV. Assim, o problema no lado do servidor é detectar se está falando com o cliente esperado (o navegador) ou não (o firewall / AV). A maneira mais segura de fazer isso é usar certificados de cliente para autenticar o cliente - e, de fato, a interceptação SSL não funcionará se a autenticação do cliente for usada, ou seja, o handshake TLS falhará, pois o MITM não é capaz de fornecer o certificado de cliente esperado. / p>

Apenas certificados de cliente são raramente usados. Além disso, um handshake TLS com falha não significaria que o cliente possa se comunicar com o servidor sem a interceptação SSL, mas que o cliente não possa se comunicar com o servidor. Uma maneira alternativa seria usar algumas heurísticas para detectar o tipo de cliente TLS com base na impressão digital do handshake TLS, ou seja, tipo e ordem de cifras, uso de extensões específicas ... Enquanto um proxy de interceptação SSL poderia, em teoria, emular o original ClientHello perfeitamente mais não. Veja também Detectar man-in-the-middle no lado do servidor para HTTPS ou na seção III Heurística de Implementação de TLS em A Segurança Impacto da interceptação HTTPS .

    

Answer 2

To me, it appears as if the employer utilizes his superior position to spy on the employee's SSL traffic. For me, this renders the whole concept of SSL untrustworthy

O problema não está no conceito de SSL nem na implementação técnica, mas sim em que outra pessoa tenha controle total sobre um ponto final da conexão, ou seja, sua estação de trabalho.
Essa é a raiz do risco de segurança real ...

De uma perspectiva de segurança, é a sua estação de trabalho comprometida que quebra a cadeia de confiança que, em circunstâncias normais, impede que um MITM seja bem-sucedido.

How can I validate the chain of trust on server side?

Você não pode. Isso é feito do lado do cliente.

Dependendo do seu caso de uso, o que você pode fazer é RFC 7469 Fixação de chave pública HTML em que você enviou um cabeçalho adicional ao cliente com uma lista (hashes) de seus certificados SSL reais ou das CAs que você usa.

    

Answer 3

Esse é o caminho errado. Não o servidor verifica a cadeia de confiança. É o cliente. Portanto, a razão pela qual a empresa usa dessa maneira é proteger o env da empresa e verificar o que o funcionário está fazendo em seu horário de trabalho.

    

Answer 4

Você COULD (tipo de), mas a verdadeira questão é se você DEVE .

Mas cuidado, não é nada tão simples quanto mudar um sinalizador no apache.conf.

Além disso, como o "atacante" (por exemplo, empregador) controla o computador cliente, eles podem sempre frustrar suas tentativas se estiverem dispostos a investir esforço suficiente (no lado positivo, a menos que você seja um peixe muito grande, eles provavelmente não estão inclinados, então você alcançará seu objetivo de que seus usuários não possam se conectar a você a menos que seja seguro) )

• você pode reimplementar o TLS no javascript e verificar se o certificado que o cliente está conectado é o certificado do seu site.

• se tiver sorte , o usuário pode estar usando o navegador onde o Javascript do lado do cliente pode obter informações sobre o certificado remoto usado (e, portanto, verificar facilmente contra o valor codificado do certificado do seu servidor).

• você pode usar o JavaScript para executar a sua criptografia personalizada . Assim, mesmo quando o malvado TLS MiTM da empresa foi bem-sucedido, ainda não lhe daria acesso aos seus dados. É claro que, se houver interesse suficiente (e eles controlarem o cliente), eles poderão substituir o seu javascript seguro por um que também registre (ou altere) todas as informações em trânsito.

Além disso, como as empresas que empregam proxies TLS MiTM geralmente controlam completamente o computador cliente, elas poderiam facilmente instalar a tela e o keylogger para simplesmente gravar vídeo de tudo o que o usuário vê e registrar todas as teclas pressionadas. . Como você pode ver, quando o atacante É o cliente, não há uma maneira absolutamente segura de enganá-lo. É realmente apenas uma questão de quanto eles vão se incomodar ... E algumas das soluções acima podem ser boas o suficiente para você.