Arrêtez de deviner : Interceptez vos flux HTTP(s) avec MITMProxy
Vous récupérez une codebase inconnue, vous savez qu’elle effectue des requêtes HTTP(s), mais vous ne savez pas vers où, ni ce qu’elle envoie ? C’est une situation classique. Nous allons voir comment intercepter et analyser ce trafic simplement.
Pour cela, nous utiliserons un proxy. C’est un intermédiaire qui se place entre votre code et le monde extérieur. Nous parlons de « Man In The Middle » (MITM). Non, aucun rapport avec Malcolm. Quoique… c’est exactement le principe : nous nous mettons au milieu pour écouter.
L’outil du jour s’appelle mitmproxy.
Section intitulée installation-de-mitmproxyInstallation de mitmproxy
C’est très simple. On récupère l’archive, on décompresse et on déplace les binaires.
# Download the binary (check https://www.mitmproxy.org/downloads/ for latest version)
wget https://downloads.mitmproxy.org/12.2.1/mitmproxy-12.2.1-linux-x86_64.tar.gz -O mitm.tgz
# Extract and cleanup
tar xzf mitm.tgz
rm mitm.tgz
# Move binaries to a global path
sudo mv mitm* /usr/local/binL’archive contient trois binaires. Nous utiliserons ici mitmweb, car il fournit une interface graphique web idéale pour débuter.
Section intitulée execution-de-mitmwebExécution de mitmweb
Démarrons le proxy avec deux options explicites :
--web-port: le port de l’interface d’administration web.--listen-port: le port d’écoute du proxy (par où transitent les requêtes).
mitmweb --web-port 9999 --listen-port 8888Ouvrez votre navigateur sur : http://127.0.0.1:9999/.
Note : Jetez un œil aux logs de mitmweb, un token de sécurité peut être requis.
Section intitulée premier-test-en-httpPremier test en HTTP
La plupart des clients HTTP (curl, symfony/http-client, clients Go/Rust…) respectent une convention : si la variable d’environnement http_proxy existe, le trafic transite par celle-ci.
Testons avec curl :
# Send a request through the proxy
http_proxy=http://localhost:8888 curl http://perdu.com
<html><head><title>Vous Etes Perdu ?</title></head><body>[...]</body></html>
Si nous regardons l’interface web, nous verrons la requête et sa réponse. C’est propre, efficace. Mais le HTTP clair, c’est de l’histoire ancienne. Passons aux choses sérieuses.
Section intitulée comment-proxifier-du-httpsComment proxifier du HTTPS ?
mitmproxy gère le HTTPS nativement. Essayons la même méthode :
https_proxy=http://127.0.0.1:8888 curl https://perdu.com
curl: (60) SSL certificate problem: unable to get local issuer certificate
[...]Échec. curl refuse la connexion. Pourquoi ?
mitmproxy n’est pas un simple passe-plat. Pour pouvoir nous montrer le contenu chiffré, il doit le déchiffrer. Pour ce faire, il « termine » la connexion SSL en se faisant passer pour le serveur final (perdu.com), puis initie une nouvelle requête vers le vrai serveur.
C’est une véritable attaque « Man In The Middle ». Sauf que curl est bien élevé : il vérifie le certificat du serveur. Comme mitmproxy signe les réponses avec son propre certificat (inconnu de votre système), curl panique et coupe tout. Heureusement !
Section intitulée solution-1-le-mode-quot-bourrin-quot-insecureSolution 1 : Le mode « Bourrin » (Insecure)
Nous pouvons demander au client d’ignorer la sécurité.
# -k or --insecure allows insecure server connections
curl -k --proxy http://127.0.0.1:8888 https://perdu.comC’est utile pour un test rapide, mais dangereux. De plus, ce n’est pas toujours possible (binaire compilé, code tiers sans option de configuration facile, etc.).
Exemple pratique avec Git :
# Check remote tags without cloning, bypassing SSL verification is risky but possible
git -c "http.proxy=127.0.0.1:8888" ls-remote --tags https://github.com/twigphp/twig
fatal: unable to access 'https://github.com/twigphp/twig/': server certificate verification failed. CAfile: none CRLfile: noneNote : nous aurions pu passer l’option -c "http.sslVerify=false", mais ca n’aide pas l’article 🙈
Section intitulée solution-2-la-methode-propre-trust-the-caSolution 2 : La méthode propre (Trust the CA)
Pour que votre système accepte mitmproxy comme une autorité légitime, nous devons ajouter son certificat racine (CA) à votre magasin de certificats local.
Au premier lancement, mitmproxy a généré ses certificats dans ~/.mitmproxy/. Sous Debian/Ubuntu, voici la procédure pour les installer proprement :
- Convertir et copier le certificat :
# Convert PEM to CRT format (if needed by your distro, usually for ca-certificates)
openssl x509 -in ~/.mitmproxy/mitmproxy-ca-cert.pem -inform PEM -out ~/.mitmproxy/mitmproxy.crt
# Copy to the CA store directory
sudo cp ~/.mitmproxy/mitmproxy.crt /usr/share/ca-certificates/extra
# Or for some systems
sudo cp ~/.mitmproxy/mitmproxy.crt /usr/local/share/ca-certificates/- Mettre à jour le store :
# Update the system's CA bundle
sudo update-ca-certificatesSi nous voyons 1 added, 0 removed; done., c’est gagné.
Nous pouvons maintenant lancer vos requêtes HTTPS sans le flag -k, elles apparaîtront en clair dans mitmweb.
https_proxy=http://127.0.0.1:8888 curl https://perdu.com
<html><head><title>Vous Etes Perdu ?</title></head><body>[...]</body></html>
Section intitulée conclusionConclusion
Vous voilà équipés pour inspecter le trafic sortant de vos applications, même chiffré. Que ce soit pour débugger une API capricieuse, reverse-engineer un SDK tiers mal documenté ou comprendre pourquoi votre CI échoue, mitmproxy lève le voile sur la « boîte noire ».
Gardez cet outil à portée de main, mais un dernier conseil : n’oubliez pas de nettoyer vos variables d’environnement (unset https_proxy) une fois le debug terminé. Sinon, vous passerez votre matinée de demain à vous demander pourquoi votre terminal n’a plus accès à Internet !
Commentaires et discussions
Ces clients ont profité de notre expertise
Dans le cadre de notre partenariat avec Carb0n, nous avons réalisé un examen complet de leur infrastructure, allant de l’environnement de production, jusqu’à au code de l’application. Nous avons fourni des recommandations stratégiques pour son amélioration. Notre intervention a notamment couvert : Évaluation et renforcement de la sécurité sur AWS, …