Filtrage web : HTTP/2 et ECH, deux angles morts que votre pare-feu ne voit pas

27 October 2026 23:11 - Par Yannick FERRY
Le banc d'essai · Infrastructure

Votre pare-feu bloque les sites indésirables. Du moins, c'est ce qu'indique son tableau de bord. Dans beaucoup d'entreprises, ce filtrage repose sur une information que les navigateurs récents ne donnent plus, ou plus toujours.

Comment votre filtrage web décide

Le trafic HTTPS est chiffré : un pare-feu ne voit pas les pages consultées. Pour filtrer sans tout déchiffrer, la plupart des solutions regardent le SNI (Server Name Indication), le nom du site que le navigateur annonce en clair au tout début de la connexion. C'est léger, rapide, et ça ne casse aucune application.

Mais toute la méthode repose sur une hypothèse : un nom annoncé égale un site visité. Cette hypothèse ne tient plus.

Angle mort n°1 : HTTP/2 réutilise la connexion

Avec HTTP/2, un navigateur peut réutiliser une connexion déjà ouverte pour un autre site, à condition que le même certificat couvre les deux noms et qu'ils pointent vers la même adresse. C'est très courant chez les grands hébergeurs et les réseaux de diffusion de contenu, où des milliers de sites partagent la même infrastructure.

Le filtre a vu un seul nom, au début. Il ne voit pas les suivants. Ce comportement, appelé connection coalescing, est prévu par la norme HTTP/2 elle-même : ce n'est pas un bug, c'est une optimisation.

Angle mort n°2 : ECH chiffre le nom du site

ECH (Encrypted Client Hello) va plus loin : le navigateur chiffre le vrai nom du site. Le filtre ne voit plus qu'un nom générique, celui de l'hébergeur. ECH est activé par défaut dans les versions récentes de Chrome et de Firefox, pour tous les sites qui le proposent, et de grands hébergeurs l'ont déployé largement.

Pour l'utiliser, le navigateur récupère une clé publiée dans le DNS, dans un enregistrement de type HTTPS. Et il le fait souvent par DNS over HTTPS, c'est-à-dire en contournant aussi les serveurs DNS de l'entreprise et le filtrage qui s'y applique.

Et HTTP/3 ? Il circule en UDP (protocole QUIC) et non plus en TCP. Selon les équipements, ce trafic est inspecté différemment, voire pas du tout. Bloquer l'UDP sur le port 443 en sortie force les navigateurs à revenir en HTTP/2.

Testez-vous en deux minutes

  1. Sur un poste de l'entreprise, ouvrez crypto.cloudflare.com/cdn-cgi/trace et cherchez la ligne sni=. Si elle indique sni=encrypted, ECH passe : votre filtre ne voit pas le nom des sites hébergés de cette façon. Si elle indique sni=plaintext, ce point est sous contrôle.
  2. Dans les paramètres du navigateur, vérifiez si le DNS sécurisé (DNS over HTTPS) est activé. S'il l'est, la résolution échappe à vos serveurs DNS.
  3. Posez la question à votre prestataire : votre filtre web déchiffre-t-il le trafic, ou s'appuie-t-il seulement sur le nom annoncé ?

Ce qu'il faut faire

Désactiver DNS over HTTPS sur les postes gérés

Par stratégie de groupe ou par votre outil de gestion des postes, pour que la résolution passe par vos serveurs DNS.

Désactiver ECH dans les navigateurs

Chrome et Edge disposent d'une stratégie dédiée. Dans Firefox, ECH dépend de DNS over HTTPS : le désactiver suffit en général.

Filtrer les enregistrements DNS de type HTTPS

Sur vos résolveurs, pour que les navigateurs ne récupèrent pas la clé ECH.

Bloquer QUIC si votre filtre ne l'inspecte pas

Fermer l'UDP 443 en sortie ramène le trafic web sur un terrain que le filtre connaît.

Réserver l'inspection complète aux cas qui la justifient

Déchiffrer le trafic voit tout, mais impose un certificat déployé sur les postes, des exceptions (banque, santé) et une information claire des salariés.

Refaire le test après chaque mise à jour majeure

Les navigateurs évoluent vite : ce qui était fermé peut se rouvrir.

Le point de vue FYS

Aucun de ces réglages n'exige d'acheter un produit : c'est de la configuration. C'est précisément le type de point que nous vérifions dans le volet réseau du diagnostic cyber, et que nous corrigeons lors d'une intégration.

En parler 30 minutes

Yannick Ferry, FYS Consulting · Le pilier Infrastructure →

p

Yannick FERRY