Configurando um proxy SSL transparente

Question

Eu tenho um linux box configurado com 2 placas de rede para inspecionar o tráfego que passa pela porta 80. Um cartão é usado para ir à Internet, o outro é ligado a um switch de rede. O objetivo é poder inspecionar todo o tráfego HTTP e HTTPS em dispositivos conectados a esse switch para fins de depuração.

Eu escrevi as seguintes regras para o iptables:

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Em 192.168.2.1:1337, eu tenho um proxy http transparente usando o Charles ( link ) para gravação.

Tudo está bem para a porta 80, mas quando adiciono regras semelhantes para a porta 443 (SSL) apontando para a porta 1337, recebo um erro sobre uma mensagem inválida por meio do Charles.

Eu usei proxy SSL no mesmo computador antes com o Charles ( link ), mas não obtiveram sucesso em fazê-lo de forma transparente por algum motivo. Alguns recursos que eu pesquisei dizem que isso não é possível - estou disposto a aceitar isso como uma resposta se alguém puder explicar o motivo.

Como observação, tenho acesso total à configuração descrita, incluindo todos os clientes ligados à sub-rede - para que eu possa aceitar certificados auto-assinados por Charles. A solução não precisa ser específica de Charles, pois, em teoria, qualquer proxy transparente serve.

Obrigado!

Edit: Depois de brincar um pouco com ele, consegui que funcionasse para um host específico. Quando modifico o meu iptables para o seguinte (e abra 1338 no charles para o proxy reverso):

nat

-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.2.1:1337
-A PREROUTING -i eth1 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 1337

-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.2.1:1338
-A PREROUTING -i eth1 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 1338

-A POSTROUTING -s 192.168.2.0/24 -o eth0 -j MASQUERADE

Eu posso obter uma resposta, mas sem host de destino. No proxy reverso, se eu apenas especificar que tudo a partir de 1338 vai para um host específico que eu queria atingir, ele executa o shake de mão corretamente e eu posso ativar o proxy SSL para inspecionar a comunicação.

A configuração é menos que ideal porque eu não quero presumir que tudo de 1338 vai para aquele host - alguma idéia de por que o host de destino está sendo retirado?

Obrigado novamente

    

Answer 1

Os problemas que você está vendo são os mesmos que impedem o uso de vários certificados em um único endereço IP / porta (sem usar o Servidor Indicação do nome) .

Em HTTP simples, seu proxy transparente pode informar a qual host o cliente deseja se conectar, examinando o cabeçalho Host .

Quando o proxy transparente do MITM HTTPS recebe a solicitação, ele não pode saber qual nome de host o cliente estava solicitando em primeiro lugar. (Eu nem tenho certeza se ele pode obter o endereço IP com essas regras, o que pode pelo menos ter permitido que ele adivinhe usando uma pesquisa reversa de DNS, mesmo que seja improvável que funcione no caso geral.)

• Para obter o nome do host esperado, o proxy MITM teria que ler o cabeçalho Host na mensagem HTTP, que só pode ocorrer após um handshake bem-sucedido.
• Para ter um handshake bem-sucedido, o proxy do MITM precisa gerar um certificado de falsificação que corresponda ao nome do host esperado.

Como resultado, o proxy MITM não pode saber qual certificado gerar antes do handshake.

Isso pode funcionar com um proxy MITM não transparente, porque você teria pelo menos o nome do host pretendido por meio do método CONNECT HTTP.

    

Answer 2

Apenas algumas informações básicas sobre este tópico.

Existem apenas alguns dispositivos que eu conheço que podem executar essa ação com êxito. No entanto, eles não estão realmente disponíveis para o público comum. Eu mesmo estou usando Fortinet Fortigate com SSL Offloading.

O que basicamente faz é; ele intercepta a conexão SSL feita ao host e descriptografa a conexão no hardware, depois inspeciona onde você quer ir e toma uma decisão de firewall com base nessas informações.

Depois, configura sua própria conexão com esse host para recuperar os dados e assinar novamente a solicitação original para o cliente usando uma CA fornecida pelo usuário. Para que isso funcione sem problemas, é necessário ter a autoridade de certificação na autoridade de certificação raiz confiável no cliente.

Esse tipo de configuração é usado nas organizações para aplicar políticas da empresa em relação ao uso da Internet. Como o uso do Active Directory é fácil de instalar a AC da sua empresa nos clientes, isso não é problema para grandes organizações.

Esta é a ÚNICA maneira de fazer isso sem criar um proxy manual, já que o tráfego SSL é criptografado. Basicamente é um MITM, por isso é importante ter quaisquer questões legais cobertas.

    

Answer 3

Há mais algumas sugestões sobre essa outra pergunta que você pode ter visto: transparente Mitos e fatos do proxy SSL . E existe este link que explica como exatamente configurar o Squid para se tornar um proxy SSL transparente. Não é o que você está procurando, mas pode pelo menos lhe dar uma ideia do que poderia estar dando errado.

As regras do iptables parecem boas, mas não tenho idéia se o software proxy que você está usando é capaz de fazer o que você está tentando fazer. A documentação certamente afirma que esse é o caso.

    

Answer 4

Para adicionar à solução de Bruno, eu investiguei um pouco e quis compartilhar como obtive mais uma correção rápida que não é ideal.

Depois de definir esses iptables, posso colocar um proxy reverso na porta 1338 e tê-lo encaminhado para localhost na porta 1337. Como a porta 1337 é um proxy http transparente e os dados foram descriptografados, ele pegará o cabeçalho do host e fará é o host de destino.

A principal desvantagem é que eu essencialmente convertei uma conexão https para http - que nem sempre funciona com todos os servidores (sem mencionar a falha de segurança que estou expondo com isso).

Eu estava trabalhando dentro dos limites do meu software. Eu acredito que uma solução mais limpa, de acordo com Bruno, seria assumir que todo o tráfego de 1338 deveria ser descriptografado. Após a descriptografia, inspecione o host de destino e, em seguida, proxy a solicitação usando SSL.