Configuration d'un proxy SSL transparent

J'ai une boîte Linux configurée avec 2 cartes réseau pour inspecter le trafic passant par le port 80. Une carte est utilisée pour sortir sur Internet, l'autre est connectée à un commutateur réseau. Le but est de pouvoir inspecter tout le trafic HTTP et HTTPS sur les appareils connectés à ce commutateur à des fins de débogage.

J'ai écrit les règles suivantes pour 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

Sur 192.168.2.1:1337, j'ai un proxy http transparent utilisant Charles ( http://www.charlesproxy.com/ ) pour l'enregistrement.

Tout va bien pour le port 80, mais lorsque j'ajoute des règles similaires pour le port 443 (SSL) pointant vers le port 1337, j'obtiens une erreur concernant un message invalide via Charles.

J'ai déjà utilisé le proxy SSL sur le même ordinateur avec Charles ( http://www.charlesproxy.com/documentation/proxying/ssl-proxying/ ), mais je n'ai pas réussi à le faire de manière transparente pour une raison quelconque. Certaines ressources que j'ai googlé disent que ce n'est pas possible - je suis prêt à accepter cela comme une réponse si quelqu'un peut expliquer pourquoi.

Comme note, j'ai un accès complet à la configuration décrite, y compris tous les clients connectés au sous-réseau - donc je peux accepter les certificats auto-signés par Charles. La solution n'a pas besoin d'être spécifique à Charles car en théorie, n'importe quel proxy transparent fera l'affaire.

Merci!

Edit: Après avoir joué avec un peu, j'ai pu le faire fonctionner pour un hôte spécifique. Lorsque je modifie mes iptables comme suit (et ouvre 1338 dans charles pour le proxy inverse):

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

Je peux obtenir une réponse, mais sans hôte de destination. Dans le proxy inverse, si je spécifie simplement que tout, à partir de 1338, va à un hôte spécifique que je voulais frapper, il effectue correctement le tremblement de la main et je peux activer le proxy SSL pour inspecter la communication.

La configuration est loin d'être idéale parce que je ne veux pas supposer que tout à partir de 1338 va à cet hôte - une idée pourquoi l'hôte de destination est supprimé?

Merci encore

Les problèmes que vous voyez sont les mêmes qui empêchent l'utilisation de plusieurs certificats sur une seule adresse IP / port (sans utiliser l'indication de nom de serveur) .

En HTTP simple, votre proxy transparent peut dire à quel hôte le client veut se connecter en regardant dans l'en- Hosttête.

Lorsque le proxy transparent HTTPS MITM obtient la demande, il ne peut pas savoir quel nom d'hôte le client demandait en premier lieu. (Je ne suis même pas sûr qu'il puisse obtenir l'adresse IP avec ces règles, ce qui pourrait au moins lui permettre de faire une supposition en utilisant une recherche DNS inversée, même s'il est peu probable qu'il fonctionne dans le cas général.)

• Afin d'obtenir le nom d'hôte attendu, le proxy MITM devrait lire l'en- Hosttête dans le message HTTP, ce qui ne peut se produire qu'après une négociation réussie.
• Afin d'avoir une négociation réussie, le proxy MITM doit générer un certificat d'usurpation correspondant au nom d'hôte attendu.

Par conséquent, le proxy MITM ne peut pas savoir quel certificat générer avant la prise de contact.

Cela peut fonctionner avec un proxy MITM non transparent, car vous obtiendriez au moins le nom d'hôte souhaité via la CONNECTméthode HTTP .

Juste quelques informations de base sur ce sujet.

Je ne connais que quelques appareils qui peuvent réussir cette action. Cependant, ils ne sont pas vraiment disponibles pour le grand public. J'utilise moi-même un Fortinet Fortigate avec déchargement SSL.

Ce qu'il fait est essentiellement; il intercepte la connexion SSL établie à l'hôte et déchiffre la connexion dans le matériel, puis inspecte où vous voulez aller et prend une décision de pare-feu en fonction de ces informations.

Ensuite, il établit sa propre connexion à cet hôte pour récupérer les données et re-signe la demande d'origine au client à l'aide d'une autorité de certification fournie par l'utilisateur. Pour que cela fonctionne sans problème, il est nécessaire d'avoir l'autorité de certification dans l'autorité de certification racine approuvée sur le client.

Ce type de configuration est utilisé dans les organisations pour appliquer les politiques de l'entreprise concernant l'utilisation d'Internet. Depuis l'utilisation d'un Active Directory, il est facile d'installer l'autorité de certification de votre entreprise dans les clients, cela ne pose aucun problème pour les grandes organisations.

C'est la SEULE façon de le faire sans créer de proxy manuel, car le trafic SSL EST crypté. Il s'agit essentiellement d'un MITM, il est donc important de couvrir tous les problèmes juridiques.

Il y a quelques autres suggestions sur cette autre question que vous avez pu voir: les mythes et les faits du proxy SSL transparent . Et il y a ce lien qui explique comment configurer exactement Squid pour devenir un proxy SSL transparent. Ce n'est pas ce que vous recherchez, mais cela pourrait au moins vous donner un aperçu de ce qui pourrait mal se passer.

Les règles iptables semblent correctes, mais je n'ai aucune idée si le logiciel proxy que vous utilisez est capable de faire ce que vous essayez de faire. La documentation affirme certainement que c'est le cas.

Pour ajouter à la solution de Bruno, j'ai enquêté un peu et je voulais partager comment j'ai obtenu une autre solution rapide moins qu'idéale.

Après avoir défini ces iptables, je peux mettre un proxy inverse sur le port 1338 et le faire suivre à localhost sur le port 1337. Comme le port 1337 est un proxy http transparent et que les données ont été déchiffrées, il prendra l'en-tête de l'hôte et en fera la destination hôte.

L'inconvénient majeur est que j'ai essentiellement converti une connexion https en http - qui ne fonctionne pas toujours avec tous les serveurs (sans parler de la faille de sécurité que j'expose à cela).

Je travaillais dans les limites de mon logiciel. Je crois qu'une solution plus propre selon Bruno serait de supposer que tout le trafic à partir de 1338 devrait être décrypté. Après le déchiffrement, inspectez l'hôte de destination, puis procurez-vous la demande à l'aide de SSL.