Inspection du trafic chiffré en 2026 : comment SASE gère TLS 1.3, QUIC et l’épinglage des certificats

TL;DR. Environ 94 % du trafic web passe désormais par HTTPS, et les protocoles sous-jacents ont changé. TLS 1.3 a supprimé les métadonnées en clair, QUIC chiffre la quasi-totalité de la poignée de main sur UDP et Encrypted ClientHello cache la destination aux proxys passifs. Les plateformes SASE modernes procèdent à des inspections sélectives, en combinant un décryptage tenant compte du protocole avec des exclusions basées sur la catégorie pour le trafic sensible à la vie privée. En 2026, la question n’est plus de savoir s’il faut tout déchiffrer, mais quel trafic doit réellement être inspecté compte tenu des changements de protocole et des contraintes de l’UE en matière de protection de la vie privée.

Environ 94 % des requêtes web utiliseront HTTPS en 2026, et les protocoles cryptographiques sous l’icône du cadenas ont évolué d’une manière qui brise l’inspection existante. Si votre passerelle web sécurisée expliquée pour SASE a été conçue pour TLS 1.2 sur TCP, elle est déjà partiellement aveugle. Cet article s’adresse aux responsables de la sécurité et de l’informatique qui choisissent comment leur plateforme Secure Access Service Edge doit gérer les compromis en matière d’inspection. Nous supposons que vous savez déjà ce que fait une passerelle web sécurisée, et nous nous concentrons donc sur la partie que la plupart des fournisseurs négligent : comment le décryptage fonctionne réellement sur TLS 1.3, ce que QUIC fait aux architectures basées sur le proxy, et pourquoi le décryptage sélectif est devenu le modèle prédominant dans les déploiements européens.

Pourquoi TLS 1.3 a mis fin à l’inspection traditionnelle

TLS 1.3, défini dans la RFC 8446, a été conçu dans un souci de protection de la vie privée. Il a supprimé l’échange de clés en clair que TLS 1.2 exposait, crypte le certificat du serveur immédiatement après la poignée de main et impose des clés Diffie-Hellman éphémères pour chaque session. Le Perfect Forward Secrecy n’est plus optionnel. Le décryptage passif hors bande, qui permet à un dispositif d’inspection de conserver une copie de la clé privée du serveur et de décrypter le trafic capturé hors ligne, ne fonctionne plus.

Le secret de session partagé est négocié à l’aide de paramètres ECDHE éphémères, signé pour chaque session et supprimé à la fin de la connexion. La compromission de la clé à long terme du serveur demain ne vous permettra pas de décrypter rétroactivement le trafic capturé hier. L’inspection d’entreprise nécessite désormais un proxy actif au niveau de la passerelle SASE qui met fin à la connexion, décrypte, recrypte jusqu’à la destination et s’appuie sur des dispositifs gérés qui font confiance à l’autorité de certification racine de la passerelle.

Dans TLS 1.2, un dispositif d’inspection pouvait analyser le SNI et le certificat du serveur en clair. Dans TLS 1.3, le certificat est chiffré dès que l’échange de clés est terminé. Combiné à la reprise anticipée des données 0-RTT, cela donne aux proxys moins de métadonnées à utiliser avant de décider d’autoriser ou non la connexion. Pour les appareils non gérés, sans AC racine d’entreprise installée, l’inspection TLS 1.3 n’est pas un problème de réglage. Elle est impossible.

ClientHello crypté modifie l’hypothèse SNI

Le dernier signal en clair dans une connexion TLS 1.3, l’extension SNI dans le ClientHello initial, est en train de disparaître. Le ClientHello chiffré, spécifié dans la RFC 9849, divise la poignée de main en un ClientHello extérieur avec un domaine de couverture générique et un ClientHello intérieur chiffré à l’aide d’un chiffrement hybride à clé publique avec une clé que le serveur publie par le biais du DNS.

L’adoption d’ECH est concentrée plutôt qu’universelle. Cloudflare applique l’ECH dans toute sa périphérie, bien qu’environ 30 % des origines hébergées par Cloudflare ne publient toujours pas de configuration ECH. Chrome, à partir de la version 117, et Firefox négocient tous deux l’ECH de manière native lorsqu’ils résolvent l’enregistrement de ressource HTTPS conformément à la RFC 9460. Edge suit le comportement de Chrome.

Le filtrage SNI, la technique légère par laquelle un proxy lit le domaine de destination à partir du ClientHello non chiffré, ne fonctionne pas lorsque l’ECH est en jeu. Deux solutions d’atténuation pour les entreprises sont en train d’émerger. La première consiste à mettre en place une politique de navigateur qui désactive l’ECH sur les appareils gérés, comme le paramètre EncryptedClientHelloEnabled de Chrome. La seconde consiste à contrôler le chemin DNS : un résolveur contrôlé par SASE peut supprimer les enregistrements de ressources HTTPS ou renvoyer NXDOMAIN pour les enregistrements qui publient les clés ECH, ce qui amène les navigateurs à revenir au comportement SNI standard. Aucune de ces solutions n’est élégante. Les deux fonctionnent.

QUIC, HTTP/3 et l’angle mort de l’inspection

QUIC, défini dans le RFC 9000, n’est pas TLS sur UDP. Il s’agit d’un nouveau protocole de transport qui intègre TLS 1.3 directement dans la couche de connexion, crypte la plupart des en-têtes de paquets, y compris les identifiants de connexion et les numéros de paquets, et fonctionne sur UDP/443 au lieu de TCP/443. HTTP/3, spécifié dans la RFC 9114, se trouve au-dessus. Pour les architectures d’inspection construites autour des proxys TCP, QUIC est un problème plus difficile que TLS 1.3.

L’adoption s’est déroulée différemment des premières prévisions. Le trafic HTTP/3 représente environ 21 % des requêtes web mondiales au deuxième trimestre 2026, bien en deçà du seuil de 30 % prédit par certains. HTTP/2 sur TCP domine toujours avec 51 %, et HTTP/1.x conserve environ 28 %. La répartition est régionale : en Italie, les parts de HTTP/3 dépassent les 30 %, tandis que les Pays-Bas et Singapour restent proches des 8-10 %. Les services qui poussent fortement QUIC, Google, YouTube, Gmail, Meta, WhatsApp et certaines parties de la pile de Microsoft, représentent une part disproportionnée du temps de l’utilisateur final.

Trois modèles architecturaux dominent les réponses des fournisseurs à QUIC. Block and fall back drops outbound UDP/443, and HTTP/3-capable browsers fall back to TLS 1.3 over TCP automatically. Il s’agit du modèle dominant, utilisé par défaut par Zscaler, Cato et Palo Alto Prisma Access. Le proxy QUIC natif termine le flux QUIC entrant au niveau d’un proxy compatible UDP, déchiffre la charge utile et se connecte à l’origine soit par QUIC, soit en rétrogradant vers HTTP/2 sur TCP. Cloudflare One prend en charge cette fonctionnalité, tout comme FortiSASE. La limitation du débit UDP avec analyse comportementale autorise l’UDP non classifié mais applique des limites strictes par connexion et une détection heuristique, généralement en tant que couche de confinement derrière l’une des deux autres.

Conséquence pratique pour les acheteurs du marché intermédiaire : si la réponse de votre fournisseur de SASE à la question « comment gérez-vous QUIC ? » est « nous le bloquons », c’est honnête, mais prévoyez des plaintes d’utilisateurs concernant les performances des vidéos et des chats. Si la réponse est « nous l’inspectons de manière native », demandez une documentation sur l’architecture du proxy et sur les combinaisons navigateur-origine qui ont été testées.

L’épinglage de certificats et les applications que vous ne pouvez pas décrypter

Même avec une inspection QUIC native et une autorité de certification racine parfaitement déployée, une partie du trafic ne sera pas décryptée. L’épinglage de certificats au niveau de l’application, où le binaire d’une application intègre l’empreinte de la clé publique de son certificat de serveur attendu et rejette tout le reste, s’est répandu bien au-delà des applications bancaires. L’épinglage de la clé publique HTTP est obsolète depuis 2018, mais l’épinglage à l’intérieur des applications mobiles et de bureau natives est toujours d’actualité et se développe.

Lorsqu’un proxy SASE intercepte une connexion épinglée, il présente à l’utilisateur un certificat de feuille signé par l’autorité de certification racine de l’entreprise. Les navigateurs l’acceptent. Les applications épinglées ne l’acceptent pas. Elles comparent la clé publique du certificat à l’identifiant codé en dur, constatent une incohérence et interrompent la connexion en émettant une alerte fatale TLS. L’utilisateur constate que l’application ne parvient pas à se connecter, souvent sans message d’erreur exploitable.

La liste des applications les plus couramment épinglées en 2026 est suffisamment longue pour influencer l’élaboration des politiques plutôt que de constituer un cas d’espèce.

L’épinglage défend les utilisateurs contre les autorités de certification malhonnêtes ou compromises, ce qui est une préoccupation légitime. Le traiter comme un obstacle à surmonter n’est pas la bonne approche. Certaines catégories de trafic ne seront pas décryptées, quelle que soit la capacité du fournisseur. Les plates-formes SASE modernes maintiennent des listes de contournement mises à jour dynamiquement qui exemptent les services épinglés et leur substituent d’autres contrôles : Le filtrage de la couche DNS, la réputation IP et les contrôles de posture des points d’extrémité. C’est l’une des raisons pour lesquelles le décryptage sélectif l’emporte sur le décryptage intégral dans la pratique.

Le DNS crypté contourne les politiques SASE par défaut

Le DNS était autrefois la couche la plus simple d’une pile de sécurité. UDP/53, texte clair, facile à enregistrer et à filtrer. Cette hypothèse ne tient plus. À la mi-2026, environ 81 à 83 % des requêtes DNS mondiales utiliseront un transport crypté, avec DoH à environ 72 %, DoT à 10-12 %, et DoQ marginal à moins de 1 %. Le taux d’utilisation du protocole UDP/53 est tombé à environ 17 %.

Les paramètres par défaut des navigateurs constituent le point de pression pratique. Chrome et Edge passent automatiquement le DNS à DoH lorsque le résolveur du système est un grand fournisseur public connu qui le prend en charge, tel que Cloudflare 1.1.1.1, Google 8.8.8.8 ou Quad9. Les deux respectent la politique de groupe de l’entreprise. Firefox est plus agressif : il active DoH par défaut dans la plupart des régions et utilise une vérification canari contre use-application-dns.net pour décider s’il faut s’en remettre au DNS local. Si ce domaine renvoie NXDOMAIN, Firefox recule. S’il renvoie une réponse normale, Firefox poursuit avec DoH et ignore complètement le serveur DNS local.

Pour les plateformes SASE qui s’appuient sur le filtrage de la couche DNS, il s’agit d’un problème structurel. Un utilisateur utilisant Firefox sur un ordinateur portable non géré peut émettre des requêtes DNS qui ne touchent jamais le résolveur de l’entreprise, ne sont jamais enregistrées et ne sont jamais filtrées. Les auteurs de logiciels malveillants l’ont remarqué. Les canaux de commande et de contrôle basés sur le DoH sont désormais une hypothèse de routine dans la réponse aux incidents.

Le schéma défensif est stratifié. Bloquez TCP/853 et UDP/853 au niveau du pare-feu pour supprimer DoT et DoQ. Résolvez le domaine canarien de Firefox en NXDOMAIN sur le résolveur de l’entreprise. Tenez à jour une liste des points de terminaison DoH publics connus. Pour le trafic décrypté en ligne, filtrez le type MIME application/dns-message afin d’empêcher le tunnelling DoH arbitraire. Aucune de ces mesures n’est à elle seule à l’épreuve des balles. Ensemble, ils restaurent suffisamment de visibilité pour être utiles.

Le décryptage sélectif est la meilleure pratique pour 2026

L’inspection complète de chaque session cryptée n’est plus l’objectif à atteindre. Elle est à peine possible techniquement à grande échelle, et même lorsqu’elle l’est, le coût en termes de protection de la vie privée et de réglementation est rarement proportionné. Les déploiements modernes de SASE utilisent un décryptage sélectif : une politique décide, pour chaque catégorie de trafic, s’il faut mettre fin à l’inspection, contourner le décryptage ou le remplacer par un autre contrôle. La norme NIST SP 800-52 Rev 2 et les orientations de l’ENISA vont dans ce sens.

La liste des exclusions est ce qui distingue une politique 2026 crédible d’une politique 2018. Les services bancaires, les soins de santé et les courriels personnels sont exemptés non seulement en raison de l’épinglage, mais aussi en raison des orientations de l’EDPB sur la surveillance du lieu de travail et du principe de proportionnalité énoncé à l’article 5 du GDPR. Les SaaS sanctionnés font l’objet d’une catégorie distincte, car le point d’inspection approprié est l’API du fournisseur, et non le réseau. Pour le trafic qui ne peut pas être décrypté et qui ne doit pas être fiable, l’isolation du navigateur déplace la surface de risque dans un conteneur cloud jetable au lieu d’essayer d’inspecter ce qui se trouve sur le câble.

Tensions en matière de protection de la vie privée et de réglementation dans les juridictions de l’UE

La capacité technique de décryptage n’est pas la même chose que l’autorité légale pour déployer le décryptage. Dans toutes les grandes juridictions de l’UE, l’inspection TLS touche à la codétermination du comité d’entreprise, à la proportionnalité du GDPR et à l’interaction avec la journalisation NIS2. Un déploiement qui ignore ces contraintes risque de rendre les journaux d’inspection légalement irrecevables en cas de conflit du travail, ce qui va à l’encontre d’une grande partie de l’objectif opérationnel.

Le Betriebsrat allemand détient, en vertu de l’article 87, paragraphe 1, point 6, de la loi sur la constitution des entreprises, des droits de codétermination contraignants sur toute mesure technique permettant de surveiller le comportement des employés. Le décryptage TLS entre dans cette catégorie. Un déploiement unilatéral sans Betriebsvereinbarung signé est juridiquement nul. Les Pays-Bas fonctionnent de la même manière avec l’Ondernemingsraad en vertu de l’article 27, paragraphe 1, point l), de la Wet op de Ondernemingsraden, où le comité d’entreprise dispose d’un droit de consentement plutôt que d’un simple droit de consultation. La France fait appel au Comité social et économique en vertu des articles L2311-1 et L2312-8 du Code du travail ; le déploiement sans l’avis formel du CSE peut faire l’objet de poursuites pour délit d’entrave, avec une responsabilité pénale pour l’employeur.

La Belgique réglemente la surveillance des communications électroniques par le biais de la convention collective de travail 81. La CCT 81 autorise la surveillance à quatre fins spécifiques : prévenir les actes illégaux ou diffamatoires, protéger les secrets d’affaires, assurer la sécurité du réseau et vérifier le respect des règles de l’entreprise. La surveillance continue et identifiée est interdite par défaut. L’employeur doit d’abord détecter une irrégularité à un niveau global, en informer l’employé, puis passer à un suivi ciblé. Cette séquence détermine directement la manière dont la journalisation du décryptage doit être configurée : pseudonymisation par défaut, identification uniquement après un événement signalé.

Les lignes directrices 05/2020 de l’EDPB sur le contrôle du lieu de travail soulignent qu’un accord d’entreprise signé n’exempte pas le déploiement du GDPR. Le traitement doit toujours reposer sur une base légale, respecter les principes de l’article 5 et faire l’objet d’une analyse d’impact relative à la protection des données en vertu de l’article 35. En pratique, c’est dans le cadre de l’analyse d’impact sur la protection des données que la liste d’exclusion du décryptage sélectif est documentée et défendue.

Le NIS2 ajoute une couche qui est souvent mal interprétée. L’article 21 exige que les entités essentielles et importantes mettent en œuvre une détection et une journalisation efficaces des menaces. Il ne précise pas le décryptage complet de TLS. Le cadre CyberFundamentals de CCB, que les organisations belges utilisent pour démontrer la conformité à NIS2, adopte une vision basée sur le risque et accepte des journaux pseudonymisés ou agrégés comme preuve de la capacité de détection. La combinaison de l’exigence de détection de NIS2 et des conseils de minimisation de l’EDPB pousse les déploiements pratiques vers exactement le modèle sélectif décrit ci-dessus.

Comment les plateformes SASE abordent l’inspection en 2026

Les principaux fournisseurs de SASE ont adopté des modèles reconnaissables, et les différences sont importantes lorsque l’on compare les plates-formes.

Une séparation architecturale claire est visible. Les fournisseurs construits sur l’héritage du proxy TCP (Zscaler, Cato, Palo Alto) traitent QUIC comme quelque chose à bloquer. Les fournisseurs ayant un héritage Edge ou NGFW étendu à UDP (Cloudflare, Fortinet) l’inspectent nativement. Ni l’un ni l’autre n’est mauvais, mais le choix a des conséquences sur l’expérience de l’utilisateur sur les services à forte intensité de QUIC et sur la complexité opérationnelle de la politique. Demandez à n’importe quel fournisseur de la documentation sur les origines spécifiques qu’il a testées dans chaque mode.

Jimber adopte une approche « cloud-native » avec un décryptage sélectif configurable par catégorie de trafic. La plateforme gère la terminaison TLS 1.3 en mode natif et prend en charge le blocage QUIC avec une politique de repli pour les organisations qui préfèrent un modèle opérationnel plus simple. La plateforme SASE de Jimber intègre l’isolation du navigateur pour le trafic qui ne doit pas être déchiffré mais qui ne doit pas non plus être fiable, et lie la couche DNS à une politique par utilisateur et par appareil. Le matériel NIAC étend les mêmes contrôles aux dispositifs sans agent tels que les imprimantes, les caméras IP et les équipements industriels qui ne peuvent pas installer d’agents de point final. L’authentification à travers ces surfaces utilise TLS mutuel, de sorte que la politique s’applique de la même manière aux ordinateurs portables gérés et à un pont IT-OT dans une usine. Étant donné que l’infrastructure est construite et exploitée dans la juridiction de l’UE, la conversation sur le DPIA part d’une position plus forte qu’avec les plates-formes basées aux États-Unis qui doivent rassembler des engagements de résidence des données autour du CLOUD Act. Pour les organisations qui passent d’une inspection basée sur des appareils à des contrôles fournis dans le nuage, notre article sur le Firewall-as-a-Service couvre le contexte plus large de l’architecture.

FAQ

Les plateformes SASE pourront-elles inspecter le trafic QUIC en 2026 ?

Certains peuvent le faire de manière native, d’autres non. Cloudflare One et FortiSASE prennent en charge l’inspection QUIC et HTTP/3 en ligne par le biais de proxys sensibles à l’UDP. Zscaler, Cato et Palo Alto Prisma Access bloquent UDP/443 pour forcer les navigateurs à revenir à TLS 1.3 basé sur TCP.

TLS 1.3 empêche-t-il l’inspection du trafic de l’entreprise ?

Non, mais cela modifie le fonctionnement de l’inspection. TLS 1.3 impose le Perfect Forward Secrecy, de sorte que le déchiffrement passif hors bande n’est plus possible. L’inspection nécessite désormais un proxy actif qui met fin à la connexion sur un appareil géré qui fait confiance à l’autorité de certification racine de l’entreprise.

Qu’est-ce que Encrypted ClientHello et cela affecte-t-il les déploiements SASE ?

ECH, spécifié dans le RFC 9849, crypte l’indication du nom du serveur à l’aide d’une clé que le serveur publie dans le DNS. Il interrompt le filtrage basé sur le SNI pour les appareils non gérés. Les plates-formes SASE atténuent généralement l’ECH en appliquant la politique du navigateur sur les appareils gérés ou en supprimant les enregistrements de ressources HTTPS au niveau du résolveur DNS de l’entreprise.

Quelles sont les applications qui utilisent l’épinglage de certificats pour empêcher le décryptage ?

Parmi les exemples les plus courants, citons WhatsApp, Signal, Apple iCloud et les services de notification push, Microsoft Teams, Slack, Salesforce, Zoom, Google Drive, Spotify, Netflix et la plupart des applications bancaires mobiles. Les applications épinglées détectent le certificat de substitution présenté par un proxy SASE et refusent de se connecter.

Le décryptage complet de TLS est-il nécessaire pour la conformité à NIS2 ?

L’article 21 de la NIS2 exige une détection efficace des menaces et une journalisation, et non un décryptage complet de chaque session. Le cadre des principes fondamentaux du cyberespace de la DGCCRF accepte le décryptage sélectif combiné à une journalisation pseudonymisée comme preuve de la capacité de détection, à condition que l’approche soit justifiée par le risque.

Comment le DNS sur HTTPS contourne-t-il le filtrage d’entreprise ?

DoH intègre les requêtes DNS dans le protocole HTTPS standard sur TCP/443, ce qui les rend impossibles à distinguer du trafic web normal sans inspection TLS en ligne. Firefox, en particulier, se met automatiquement à jour vers DoH et peut contourner entièrement les résolveurs d’entreprise. Les mesures d’atténuation comprennent le blocage des points de terminaison DoH connus, le renvoi de NXDOMAIN pour les domaines canaris et le filtrage du type MIME application/dns-message.

Qu’est-ce que le décryptage sélectif TLS et quand doit-il être utilisé ?

Le déchiffrement sélectif applique une politique de déchiffrement par catégorie de trafic, exemptant les catégories sensibles telles que les banques, les soins de santé et les SaaS sanctionnés, tout en inspectant le trafic web général et le stockage dans le nuage. Cette approche devrait être l’approche par défaut pour toute organisation opérant dans le cadre du GDPR ou des comités d’entreprise de l’UE, car elle répond directement aux obligations de proportionnalité et de minimisation tout en préservant une inspection significative.

L’inspection du chiffrement en 2026 est devenue moins une question de capacité technique qu’une question de savoir quel trafic a réellement besoin d’être ouvert. Les changements de protocole ont fermé les voies faciles, et la législation européenne sur la protection de la vie privée a fermé la plupart des voies de force brute. Une plateforme SASE qui gère nativement la terminaison TLS 1.3, fait un choix délibéré de QUIC, prend en charge le décryptage sélectif configurable par catégorie et intègre l’isolation du navigateur pour le trafic qui ne peut ou ne doit pas être décrypté donne aux équipes du marché intermédiaire une position défendable sous l’examen de NIS2 et du comité d’entreprise. Si vous souhaitez voir comment Jimber configure cette solution pour un environnement de PME européen, réservez une démonstration et nous passerons en revue le cadre de politique avec vous.