Pendant que Burp Suite avale 500 Mo de RAM au démarrage, HTTP Breakout Proxy lui, tient dans un binaire de quelques Mo qui disparaît dès que vous fermez le terminal.

Alors HTTP Breakout Proxy c’est quoi ?

Hé bien les amis, c’est un proxy HTTP/HTTPS écrit en Go qui intercepte le trafic réseau en temps réel et vous propose une interface web pour analyser tout ce qui passe. Requêtes, réponses, headers, body, timing… Tout est capturé et affiché proprement dans votre navigateur.

Vous le lancez avec ./http-breakout-proxy, il écoute sur 127.0.0.1:8080, et vous ouvrez l’interface dans votre browser. Ensuite, si vous voulez débugger une API par exemple, vous lancez le proxy, vous configurez votre client HTTP pour passer par localhost:8080, et vous voyez tout passer en direct.

C’est vrai que Burp est devenu un monstre à tout faire avec scanner de vulnérabilités, fuzzer, crawler, extensions… Y’a aussi Charles Proxy que j’aime bien mais qui pèse dans les 100 Mo et nécessite une JVM complète. Et même mitmproxy , pourtant réputé léger, a accumulé tellement de fonctionnalités qu’il faut lire 50 pages de doc pour comprendre comment l’utiliser.

Avec HTTP Breakout Proxy, il y a moins de features c’est vrai mais ça va plus vite et c’est gratuit. Maintenant, au niveau technique, le projet utilise l’interception MITM classique. Vous installez le certificat racine fourni par le proxy, et il peut déchiffrer le trafic HTTPS qui passe par lui. Ensuite, l’interface web affiche tout en temps réel via Server-Sent Events. Vous avez du filtrage par regex, du color-coding configurable pour repérer visuellement les requêtes importantes, et même des charts Gantt pour visualiser le timing des connexions…etc.

Que demande le peuple ? Ah oui, y’a aussi l’export vers curl ou Python requests, ce qui est pratique quand vous voulez rejouer une requête dans un script. Et bien sûr la possibilité de mettre la capture en pause pour analyser tranquillement ce qui s’est passé.

Voilà, c’est minimaliste mais ça marche hyper bien et quand on est pas un pro de la sécurité, c’est bien d’avoir des outils de ce style pour explorer un truc vite fait. Et merci à Lorenper pour le partage !

A découvrir ici !

Google et le CA/Browser Forum viennent d’annoncer la mise à mort de 11 méthodes de validation de domaine pour les certificats HTTPS. Bye bye les emails, les coups de fil, les fax (oui, y’en avait encore qui utilisaient ça) et le courrier postal pour valider les certificats car d’ici mars 2028, tout ça sera du passé.

Car quand vous demandez un certificat SSL/TLS pour votre site, l’autorité de certification doit vérifier que vous êtes bien le proprio du domaine. Historiquement, ça pouvait se faire via un email envoyé à l’adresse WHOIS, un coup de téléphone, ou même un courrier papier mais le problème, c’est que ces méthodes sont faciles à falsifier.

Des chercheurs en sécurité ont montré qu’il était possible de manipuler les données WHOIS ou d’intercepter les communications pour obtenir des certificats frauduleux et quand, malheureusement, un attaquant peut se faire passer pour le propriétaire légitime d’un domaine et obtenir un vrai certificat, ça ouvre la porte à des attaques man-in-the-middle bien méchantes.

Donc le CA/Browser Forum a voté le ballot SC-090 pour éliminer progressivement ces vieilles méthodes. Juin 2025 a vu la fin de la validation WHOIS par email, mars 2026 découragera l’utilisation des méthodes email en général, et mars 2028 ce sera le grand ménage final.

À la place, il faudra donc passer par des méthodes plus directes tels qu’un enregistrement DNS TXT avec une valeur aléatoire que l’autorité vérifiera, ou un fichier HTTP placé à un endroit précis de votre serveur. Ces méthodes permettent de prouver cryptographiquement que vous contrôlez bien le domaine, sans intermédiaire chelou.

Pour les utilisateurs lambda, ça ne change rien évidemment, vous continuerez à voir le petit cadenas dans votre navigateur. Mais pour les admins système et les responsables de sites, ça veut dire qu’il va falloir automatiser tout ça. Si vous utilisez encore des certificats validés par email, c’est donc le moment de migrer vers des outils comme ACME (le protocole derrière Let’s Encrypt).

Ce mouvement s’inscrit également dans une tendance plus large puisque le ballot SC-070 prévoit aussi de réduire la durée de validité des certificats pour les passer à 10 jours de réutilisation de la validation dès mars 2028, puis des certificats de 47 jours seulement en mars 2029. Donc autant dire que sans automatisation, ça va devenir ingérable.

Google pousse donc clairement l’écosystème vers plus de sécurité, quitte à forcer la main aux retardataires. Moins de maillons dans la chaîne, c’est moins d’opportunités pour les attaquants et je trouve que c’est plutôt une bonne nouvelle.

Source