Configurar un proxy SSL transparente

Tengo una caja de Linux configurada con 2 tarjetas de red para inspeccionar el tráfico que pasa por el puerto 80. Una tarjeta se usa para salir a Internet, la otra está conectada a un conmutador de red. El punto es poder inspeccionar todo el tráfico HTTP y HTTPS en los dispositivos conectados a ese conmutador para fines de depuración.

He escrito las siguientes reglas para 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

En 192.168.2.1:1337, obtuve un proxy HTTP transparente usando Charles ( http://www.charlesproxy.com/ ) para grabar.

Todo está bien para el puerto 80, pero cuando agrego reglas similares para el puerto 443 (SSL) que apunta al puerto 1337, recibo un error sobre un mensaje no válido a través de Charles.

He usado proxy SSL en la misma computadora antes con Charles ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), pero por alguna razón no he podido hacerlo de manera transparente. Algunos recursos que busqué en Google dicen que no es posible; estoy dispuesto a aceptar eso como respuesta si alguien puede explicar por qué.

Como nota, tengo acceso completo a la configuración descrita, incluidos todos los clientes conectados a la subred, por lo que puedo aceptar certificados autofirmados por Charles. La solución no tiene que ser específica de Charles ya que, en teoría, cualquier proxy transparente funcionará.

¡Gracias!

Editar: después de jugar un poco, pude hacerlo funcionar para un host específico. Cuando modifico mis iptables a lo siguiente (y abro 1338 en charles para proxy inverso):

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

Puedo obtener una respuesta, pero sin host de destino. En el proxy inverso, si solo especifico que todo desde 1338 va a un host específico que quería golpear, realiza el apretón de manos correctamente y puedo activar el proxy SSL para inspeccionar la comunicación.

La configuración es menos que ideal porque no quiero asumir que todo, desde 1338, va a ese host, ¿alguna idea de por qué el host de destino está siendo eliminado?

Gracias de nuevo

Los problemas que está viendo son los mismos que impiden el uso de múltiples certificados en una sola dirección / puerto IP (sin usar la Indicación del nombre del servidor) .

En HTTP simple, su proxy transparente puede decir a qué host quiere conectarse el cliente mirando el Hostencabezado.

Cuando el proxy transparente HTTPS MITM recibe la solicitud, no puede saber qué nombre de host solicitó el cliente en primer lugar. (Ni siquiera estoy seguro de que pueda obtener la dirección IP con estas reglas, lo que al menos podría haberle permitido adivinar usando una búsqueda inversa de DNS, aunque es poco probable que funcione en el caso general).

• Para obtener el nombre de host esperado, el proxy MITM tendría que leer el Hostencabezado en el mensaje HTTP, lo que solo puede ocurrir después de un apretón de manos exitoso.
• Para tener un protocolo de enlace exitoso, el proxy MITM necesita generar un certificado falso que coincida con el nombre de host esperado.

Como resultado, el proxy MITM no puede saber qué certificado generar antes del protocolo de enlace.

Esto puede funcionar con un proxy MITM no transparente, porque al menos obtendría el nombre de host deseado a través del CONNECTmétodo HTTP .

Solo información básica sobre este tema.

Solo conozco algunos dispositivos que pueden llevar a cabo esta acción con éxito. Sin embargo, no están realmente disponibles para el público en general. Yo mismo estoy usando un Fortinet Fortigate con descarga de SSL.

Lo que básicamente hace es; intercepta la conexión SSL realizada con el host y descifra la conexión en hardware, luego inspecciona a dónde quiere ir y toma una decisión de firewall basada en esa información.

Luego, establece su propia conexión con ese host para recuperar los datos y vuelve a firmar la solicitud original al cliente utilizando una CA proporcionada por el usuario. Para que esto funcione sin problemas, es necesario tener la CA en la CA raíz de confianza en el cliente.

Este tipo de configuraciones se utilizan en las organizaciones para hacer cumplir las políticas de la empresa con respecto al uso de Internet. Dado que usar un Active Directory es fácil instalar la CA de su empresa en clientes, esto no supone un problema para las grandes organizaciones.

Esta es la ÚNICA forma en que puede hacerlo sin crear un proxy manual, ya que el tráfico SSL ESTÁ encriptado. Básicamente es un MITM, por lo que es importante tener cubiertos los problemas legales.

Hay algunas sugerencias más sobre esta otra pregunta que puede haber visto: mitos y hechos transparentes sobre proxy SSL . Y existe este enlace que explica cómo configurar exactamente Squid para convertirse en un proxy SSL transparente. No es lo que está buscando, pero al menos podría darle una idea de lo que podría estar yendo mal.

Las reglas de iptables parecen estar bien, pero no tengo idea si el software proxy que está usando puede hacer lo que está tratando de hacer. La documentación ciertamente afirma que este es el caso.

Para agregar a la solución de Bruno, investigué un poco y quería compartir cómo obtuve otra solución rápida menos que ideal.

Después de configurar esas iptables, puedo poner un proxy inverso en el puerto 1338 y enviarlo a localhost en el puerto 1337. Dado que el puerto 1337 es un proxy http transparente y los datos han sido descifrados, tomará el encabezado del host y lo convertirá en el destino anfitrión.

El principal inconveniente es que esencialmente he convertido una conexión https a http, que no siempre funciona con todos los servidores (sin mencionar el agujero de seguridad que estoy exponiendo).

Estaba trabajando dentro de los límites de mi software. Creo que una solución más limpia según Bruno sería asumir que todo el tráfico de 1338 debería ser descifrado. Después del descifrado, inspeccione el host de destino y luego delegue la solicitud usando SSL.