Mitmproxy 11 : prise en charge complète de HTTP/3

 (mitmproxy.org)
3 points par GN⁺ 2024-10-06 | 1 commentaires | Partager sur WhatsApp
  • Alors que la part du trafic QUIC et HTTP/3 augmente, mitmproxy 11 active HTTP/3 par défaut, élargissant ainsi l’analyse du trafic web moderne
  • HTTP/3 fonctionne non seulement en proxy transparent et en proxy inverse, mais aussi avec WireGuard et le mode local, ce qui le rend applicable à divers environnements de capture
  • Chrome ne fait pas confiance, avec QUIC, à une autorité de certification ajoutée par l’utilisateur ; il faut donc choisir entre un certificat publiquement approuvé, des options de ligne de commande ou un repli vers HTTP/2
  • L’implémentation DNS est désormais reconstruite sur Hickory DNS, avec prise en charge des requêtes autres que A/AAAA, des HTTPS records, du DNS-over-TCP, du contrôle du fichier hosts et de la suppression des clés ECH
  • Les fonctions de confidentialité comme ECH compliquent la génération de certificats pour un proxy d’interception, mais mitmproxy conserve cette possibilité en ajustant les réponses DNS

Portée de la prise en charge de HTTP/3

  • mitmproxy 11 prend en charge HTTP/3 en mode proxy transparent et proxy inverse
  • En proxy inverse, une seule instance de mitmproxy reçoit à la fois les paquets TCP et UDP et traite la version HTTP transmise
  • WireGuard et le mode local peuvent également utiliser HTTP/3
    • Exemples de commandes : 
      mitmproxy --mode wireguard
mitmproxy --mode local
  • Des tests ont été effectués avec Firefox, Chrome, plusieurs builds de cURL et d’autres clients afin de réduire les problèmes de compatibilité
  • Le travail sur la prise en charge de HTTP/3 a été lancé en 2022 par Manuel Meitinger et Maximilian Hils, puis activé par défaut dans mitmproxy 11

Contraintes de certificats QUIC dans Chrome

  • La principale limitation connue à ce jour est que Chrome ne fait pas confiance, avec QUIC, à une autorité de certification ajoutée par l’utilisateur
  • Pour traiter le trafic HTTP/3 dans Chrome, l’une des options suivantes est nécessaire
    • Fournir un certificat publiquement approuvé, comme Let’s Encrypt
    • Lancer Chrome avec les options de ligne de commande appropriées
    • Accepter un comportement de repli vers HTTP/2
  • Firefox ne présente pas ce comportement
  • Des conseils de dépannage pour HTTP/3 sont disponibles dans #7025

Réimplémentation basée sur Hickory DNS

  • Avec l’arrivée de fonctions de confidentialité comme les DNS HTTPS records et Encrypted Client Hello (ECH), le traitement DNS de mitmproxy gagne en importance
  • L’implémentation DNS existante avait des limites car elle utilisait getaddrinfo
    • Elle ne prenait en charge que les requêtes A/AAAA pour les adresses IPv4 et IPv6
    • Elle ne pouvait pas répondre à des requêtes comme les HTTPS records qui signalent la prise en charge de HTTP/3
  • mitmproxy 11 réimplémente le support DNS au-dessus de Hickory DNS, une bibliothèque DNS en Rust
  • Grâce à Hickory, mitmproxy récupère les serveurs de noms par défaut du système sur Windows, Linux et macOS, et relaie vers eux les requêtes autres que A/AAAA
  • La nouvelle option dns_name_servers permet de définir les serveurs de noms de destination 
    mitmdump --mode dns --set dns_name_servers=8.8.8.8

Contrôle du fichier hosts et DNS-over-TCP

  • Avec la migration vers Hickory, une option a été ajoutée pour ignorer le fichier hosts du système
  • La nouvelle option dns_use_hosts_file permet de contrôler si les fichiers hosts comme /etc/hosts sur Linux sont pris en compte
  • Il est prévu de migrer aussi la résolution DNS interne de mitmproxy vers Hickory ; cette fonction deviendra alors utile pour les redirections transparentes d’un domaine spécifique sur la même machine
    • Actuellement, comme le fichier hosts est toujours pris en compte, mitmproxy peut se reconnecter récursivement à lui-même lors d’une configuration de redirection sur la même machine
  • Exemple de comportement : 
    echo "192.0.2.1 mitmproxy.org" >> /etc/hosts
mitmdump --mode dns
dig @127.0.0.1 +short mitmproxy.org
192.0.2.1
mitmdump --mode dns --set dns_use_hosts_file=false
dig @127.0.0.1 +short mitmproxy.org
3.161.82.13
  • Le DNS utilise UDP par défaut, mais TCP peut être nécessaire pour traiter des enregistrements qui ne tiennent pas dans un seul paquet UDP
  • Comme mitmproxy 11 prend en charge des types de requêtes arbitraires, l’importance de la taille des messages et du traitement TCP augmente, et DNS-over-TCP fonctionne également

Suppression des clés ECH et génération de certificats

  • Lorsqu’aucun certificat personnalisé n’est disponible, mitmproxy utilise le Server Name Indication (SNI) du TLS ClientHello pour construire un certificat valide
  • En l’absence de SNI, il peut être impossible de générer un certificat auquel le client fera confiance
  • Encrypted Client Hello (ECH) permet au client d’obtenir des clés ECH via les DNS HTTPS records, puis de chiffrer avec ces clés le message initial de handshake ClientHello
  • Si la requête DNS et le handshake sont tous deux chiffrés, un intermédiaire passif ne peut pas connaître le domaine cible et ne voit que l’adresse IP cible
    • En hébergement mutualisé et avec les Content Delivery Networks, il est difficile de déterminer le domaine cible à partir de la seule adresse IP
  • Cette amélioration de la confidentialité entre en conflit avec la manière dont mitmproxy génère les certificats
  • mitmproxy 11 supprime les clés ECH des HTTPS records afin d’obtenir les informations de domaine nécessaires à la génération des certificats
    • Le client ne peut pas obtenir la clé permettant de chiffrer le message initial de handshake
    • mitmproxy peut identifier le domaine cible et construire un certificat correspondant
  • ECH peut rendre l’usage de mitmproxy plus difficile, mais cela peut aussi être vu comme une évolution qui renforce la confidentialité sur l’ensemble du web

À lire aussi

1 commentaires

 
GN⁺ 2024-10-06
Avis sur Hacker News

  • Content de voir que Mitmproxy est encore développé. Cet outil a indirectement façonné ma carrière.
    En 2011, j’apprenais à développer des API en interceptant les requêtes d’apps mobiles, et j’ai découvert que l’API d’Airbnb était exposée à la vulnérabilité d’assignation de masse de Rails (https://github.com/rails/rails/issues/5228). Après avoir modifié quelques attributs sans conséquence, j’ai contacté l’entreprise, ce qui a débouché sur un entretien, et la suite appartient littéralement à l’histoire.

    • Le nombre de développeurs principaux qui s’opposaient au changement dans cette issue était vraiment aberrant.
    • Même aujourd’hui, ça m’est extrêmement utile, mais étonnamment beaucoup de gens pourtant bien informés connaissent mal Mitmproxy.
      Parfois, il est plus simple de brancher mitmproxy sur une implémentation existante que de lire la documentation.

  • Il est intéressant que Chrome ne fasse pas confiance, pour QUIC, aux autorités de certification ajoutées par l’utilisateur.
    Dans l’issue liée, l’équipe Chrome explique : « Nous n’autorisons pas explicitement les certificats qui ne sont pas publiquement approuvés afin d’empêcher le déploiement de logiciels/matériels d’interception QUIC. Sinon, cela nuirait à long terme à la capacité d’évolution du protocole QUIC. Les usages qui dépendent de certificats non publiquement approuvés peuvent utiliser TLS+TCP au lieu de QUIC. »
    Je ne suis pas l’évolution du protocole, mais je ne vois pas bien en quoi bloquer les certificats personnalisés est lié à la capacité d’évolution. Je serais curieux de savoir si quelqu’un connaît la raison.

    • À mon avis, comme Google contrôle à la fois le client et de gros endpoints serveur (Google Search, Youtube, etc.), ils veulent pouvoir expérimenter librement des modifications de QUIC.
      Ils peuvent intégrer dans Chrome une version légèrement modifiée de QUIC, la prendre en charge sur des services comme Youtube, puis, sur la base des métriques obtenues, proposer une « vraie » modification du standard ou continuer à faire tourner une version spéciale uniquement sur leurs propres services.
      Autoriser les certificats personnalisés risquerait de casser, lors de changements de protocole, les entreprises qui inspectent le trafic de leurs employés par attaque de l’homme du milieu avec des solutions comme ZScaler ZIA. Si le flux de données est entièrement chiffré et opaque pour les équipements intermédiaires, Google peut faire à peu près ce qu’il veut.
      Concept lié : https://en.wikipedia.org/wiki/Protocol_ossification
    • Les équipements intermédiaires (https://en.m.wikipedia.org/wiki/Middlebox) sont une cause bien connue d’ossification des protocoles.
      Un protocole extensible ne nécessite généralement de mettre à niveau que le client et le serveur, mais avec des équipements intermédiaires, il faut potentiellement aussi mettre à jour N appareils. Les utilisateurs et les fournisseurs de services ont une motivation à adopter de nouvelles fonctionnalités, mais les propriétaires d’équipements intermédiaires n’en ont pas forcément. Résultat : le protocole devient difficile à faire évoluer.
    • Cela fait peut-être référence au cas célèbre des institutions financières qui se sont opposées à TLS 1.3. Leur motivation était de ne pas vouloir mettre à jour les logiciels d’interception nécessaires à la conformité réglementaire : https://mailarchive.ietf.org/arch/msg/tls/CzjJB1g0uFypY8UDdr6P9SCQBqA/
    • L’une des raisons pour lesquelles HTTP/2 et HTTP/3 ont été créés est aussi que les modifications de HTTP 1.1 étaient trop difficiles.
      Beaucoup de middlewares dépendaient fortement de détails d’implémentation, si bien qu’un petit changement pouvait facilement casser l’expérience utilisateur de façon imprévue. Il semble qu’ils cherchent à éviter une situation similaire dans les nouvelles versions.
    • QUIC existe pour augmenter le taux de livraison des publicités ; donner de la liberté à l’utilisateur entre donc en conflit avec cet objectif.

  • Je me demande s’il y a un bénéfice à ce que HTTP/2 ou HTTP/3 soit pris en charge uniquement par les reverse proxies, et pas par les vrais serveurs web.
    La plupart des frameworks dominants en JS/Python/Ruby ne prennent pas en charge les nouveaux standards HTTP. Dans ce cas, le serveur web ne devient-il pas le goulot d’étranglement de la connexion au reverse proxy ?

    • Oui. HTTP/2 ou HTTP/3 améliorent la fiabilité de la connexion entre le client et le reverse proxy.
      La connexion entre le reverse proxy et le vrai serveur web est généralement beaucoup plus rapide et stable ; passer ce segment en HTTP/2 ou HTTP/3 apporte donc un gain bien moindre.
    • Le transport entre le reverse proxy et le backend n’est pas non plus toujours en HTTP. Par exemple, Python utilise parfois uWSGI, et PHP FastCGI.
      Même quand HTTP est utilisé, le reverse proxy peut établir une connexion avec le backend bien plus rapidement qu’avec le vrai client distant. Utiliser des streams HTTP/2 sur le segment lent reste donc avantageux.
    • Cela n’a probablement pas grande importance, mais mitmproxy n’est pas un reverse proxy destiné à la production.
      C’est un outil que l’on exécute sur sa machine locale pour faire des tests liés aux protocoles bas niveau ou à la sécurité web.
    • Il manque un point : les navigateurs web limitent le nombre de connexions par domaine à 6.
      Avec HTTP/2 et versions ultérieures, plusieurs requêtes simultanées passent par une seule connexion.
    • Oui. Il y a d’autres gains de performance, mais HTTP/3 combine les handshakes TCP et TLS et réduit ainsi la connexion d’un aller-retour.

  • Il reste encore le problème de fingerprinting. Tant qu’il ne pourra pas imiter le handshake TLS d’un navigateur courant, on verra sur environ 80 % du web des pages du type « Just a quick check... » ou « Sorry, it looks like you're a bot ».
    https://github.com/mitmproxy/mitmproxy/issues/4575

    • Dans ce cas, Firefox n’est apparemment plus un navigateur courant.

  • Merci d’avoir mentionné Hickory. C’est toujours amusant de voir ce que les gens construisent avec, et c’est du beau travail.

    • Merci pour le travail sur Hickory. Grâce à l’interopérabilité Python↔Rust de PyO3, il est vraiment intéressant de pouvoir utiliser depuis Python des bibliothèques DNS de qualité production comme Hickory et des piles réseau userspace solides comme smoltcp.
      Ce sont des choses qu’il aurait été difficile d’obtenir avec Python seul.

  • Je me demande si Mitmproxy peut être utilisé comme Privoxy/Proxomitron/Yarip.
    Par exemple, en naviguant avec Ungoogled Chromium, peut-on mettre Mitmproxy comme proxy et supprimer les balises script de certains sites ? Quel serait l’impact sur les performances ?

    • En théorie, oui. En pratique, mitmproxy est écrit en Python, donc comme le langage n’est pas particulièrement rapide, cela ajoute de la latence.
      Quand on consulte une page web, de petits délais qui s’accumulent des centaines de fois peuvent se faire sentir.
      Cela dit, pour les personnes intéressées par cet usage, ça peut être une option. Techniquement, rien ne l’empêche.
      En réécrivant des fichiers JavaScript, il y a un petit risque de toucher aux contrôles d’intégrité des sous-ressources, mais si cela pose problème en pratique, il devrait être possible de réécrire aussi les hashes.

  • mitmproxy peut-il remplacer Fiddler ?

  • Hmm : https://github.com/mitmproxy/mitmproxy/issues/4170