Règle HTTP

Il existe 4 types de règles de niveau HTTP. USER-AGENT et URL-REGEX lisent la requête qu'un client envoie à l'écouteur du proxy HTTP de Chute ; elles ne correspondent donc qu'aux connexions qui y arrivent : une connexion passant par TUN ou SOCKS5 n'a pas de requête HTTP à lire. Leur verdict est établi une seule fois par connexion client, d'après sa première requête. Le déchiffrement MitM commence après le choix de la politique d'une connexion : les requêtes qu'il déchiffre ne sont donc pas confrontées de nouveau aux règles. PROTOCOL,TCP et PROTOCOL,UDP lisent la couche transport et correspondent sur toute entrée ; les valeurs de protocole applicatif de PROTOCOL proviennent de la détection de protocole de l'entrée TUN, et d'une requête simple sur l'entrée proxy HTTP. SCRIPT est évaluée pour toute connexion.

USER-AGENT

USER-AGENT,Instagram*,DIRECT

La règle correspond si l'agent utilisateur de la requête correspond. Les caractères joker * et ? sont pris en charge. L'en-tête est lu dans la première requête de chaque connexion client à l'écouteur du proxy HTTP ; pour HTTPS, cette requête est le CONNECT par lequel le client ouvre son tunnel, si bien que la règle voit le User-Agent que le client place sur le CONNECT, s'il en envoie un.

URL-REGEX

URL-REGEX,^http://google\.com.*,DIRECT

La règle correspond si l'URL d'une requête HTTP en clair arrivant sur l'écouteur du proxy HTTP correspond à l'expression régulière. L'URL est écrite en entier — http://host[:port]/path?query, le port étant omis lorsqu'il vaut 80 — et l'expression régulière doit correspondre à l'URL complète, et non à une simple sous-chaîne : ^http://google\.com seul ne correspond pas à http://google.com/, car le chemin fait partie de l'URL. Un tunnel CONNECT (HTTPS, ou tout autre trafic qu'un client fait passer par un tunnel) et une connexion TUN n'ont pas d'URL : URL-REGEX ne leur correspond donc jamais, et déchiffrer une connexion HTTPS par MitM n'y change rien. Le test à blanc de correspondance des règles, POST /api/rules/match de l'API de contrôle HTTP, confronte URL-REGEX à son champ url exactement tel qu'il est envoyé : donnez-lui donc l'URL complète.

PROTOCOL

PROTOCOL,TLS,Proxy

La règle correspond si le protocole détecté de la connexion correspond. À utiliser avec sniffing-enabled pour de meilleurs résultats. NETWORK est accepté comme alias de PROTOCOL.

Valeurs de protocole acceptées : HTTP, HTTPS, TLS, TCP, UDP, QUIC, STUN, MTPROTO, DNS, DOH, DOH3, DOQ, DOT.

Remarque : le protocole détecté est renseigné aux endroits suivants. Pour les sessions entrantes TUN, avec sniffing-enabled activé, une connexion TCP n'est détectée comme HTTP ou TLS (toute connexion TLS, y compris HTTPS) que lorsque Chute ne connaît pas déjà son nom d'hôte : une connexion ouverte vers une fausse IP, ou vers une adresse que le DNS de Chute a résolue, conserve ce nom et n'est pas soumise à la détection, si bien que PROTOCOL,HTTP et PROTOCOL,TLS correspondent rarement au trafic TUN dont les noms ont été résolus par Chute. Un flux UDP est détecté comme QUIC d'après la forme de ses paquets — par TUN comme par le relais UDP de l'entrée SOCKS5 — sans que sniffing-enabled soit nécessaire. Avec sniffing-enabled activé, Chute lit aussi le nom du serveur dans le paquet Initial d'un flux QUIC, de sorte que les règles de type DOMAIN peuvent également correspondre à ce flux (voir sniffing-enabled dans Options diverses). Sur l'entrée proxy HTTP, une requête simple (sans CONNECT) est HTTP sans aucune détection, puisque son en-tête de requête vient d'être analysé sur la connexion ; un CONNECT laisse le protocole non renseigné, et une connexion TCP sur l'entrée SOCKS5 n'en reçoit jamais — mais PROTOCOL,TCP et PROTOCOL,UDP lisent la couche transport de la session, que chaque entrée renseigne, de sorte que ces deux règles y correspondent aussi. Avec encrypted-dns-follow-outbound-mode = true (voir Serveur DNS), les connexions de Chute lui-même vers les serveurs DNS chiffrés sont évaluées comme DOH, DOT, DOQ et DOH3 : les quatre utilisent alors la politique nommée par la règle — DoQ et DoH3 par son relais UDP, udp-policy-not-supported-behaviour tranchant quand elle n'en a pas — et une décision REJECT écarte n'importe laquelle des quatre. HTTPS est une graphie acceptée d'une poignée de main TLS détectée : PROTOCOL,HTTPS et PROTOCOL,TLS correspondent donc au même trafic. STUN, MTPROTO et DNS sont acceptées pour la compatibilité, mais aucun détecteur ne les produit encore.

SCRIPT

SCRIPT,MyRuleScript,DIRECT

La règle évalue un script JavaScript pour une logique de correspondance personnalisée. Le nom du script doit correspondre à un script défini dans la section [Script] avec type=rule.

[Rule]
SCRIPT,CheckInternal,PROXY

[Script]
CheckInternal = type=rule, script-path=internal-check.js

Le script de règle reçoit $request et doit appeler $done({matched: true}) ou $done({matched: false}). Notez que $request.dnsResult n'est disponible que lorsque la session a déjà été résolue (par exemple, pour les requêtes adressées directement à une adresse IP, ou lors de la seconde passe de correspondance après résolution DNS).