Si vous voyez l'un des symptômes ci-dessous même après avoir activé le VPN, suspectez une fuite DNS ou une fuite WebRTC. Une fuite se produit lorsque des informations censées passer par le chemin VPN quittent ce chemin (également appelée exfiltration).
- L'IP du serveur VPN est affichée sur la page de vérification IP, mais le serveur DNS de l'entreprise de télécommunication ou du routeur est affiché dans le test DNS.
- L'adresse IPv4 a changé, mais l'adresse IPv6 est la même qu'avant la désactivation du VPN.
- Sur la page de test WebRTC, l'adresse IP publique apparaît telle qu'elle était avant la désactivation du VPN.
- L'adresse IP d'origine n'est visible qu'immédiatement après le passage du Wi-Fi aux données mobiles ou la sortie du mode veille.
- J'ai activé StageVPN pour Chrome, mais d'autres navigateurs et programmes PC se connectent en utilisant l'adresse IP d'origine.
- Même avec le VPN activé, le site affiche la langue et le contenu en fonction de la région d'origine (cela peut être dû aux paramètres du compte/des cookies).
La fuite DNS est un phénomène dans lequel la communication Web passe par le tunnel lorsque le VPN est activé, mais seules les requêtes DNS sortent du tunnel et le nom de domaine est visible par le serveur DNS de l'entreprise de télécommunication ou du Wi-Fi. La fuite WebRTC est un phénomène dans lequel le WebRTC du navigateur envoie une requête STUN directement depuis le VPN/proxy, permettant à la page Web de découvrir l'adresse IP publique réelle. Aucun de ces phénomènes ne signifie que le contenu de la page fuit. Cependant, il révèle « qui accède à où ». Cet article commence par les symptômes et passe par six étapes de diagnostic, de résolution par cause et de réexamen.

Diagnostic : Comment rechercher une fuite en 6 étapes
Le principe de la vérification des fuites est de comparer les valeurs avec le VPN désactivé et avec celui-ci activé. Comparez l'adresse IP affichée sur le site, le serveur qui a reçu la requête DNS et l'adresse du candidat WebRTC. Si les valeurs d'origine sont visibles même après avoir activé le VPN, il s'agit d'une fuite. Les tests n'ont de sens que sur les appareils et les navigateurs que vous utilisez réellement. Même si vous ne disposez pas d'un site de test spécifique, vous pouvez vérifier la plupart des choses simplement en utilisant un navigateur. La page de vérification IP est une page Web qui affiche l'adresse IP publique de la personne connectée à l'écran. Vous pouvez le trouver dans un moteur de recherche sous « Vérifier l’IP ». Recherchez la page de test de fuite DNS et la page de test WebRTC de la même manière. Le principe est le même quelle que soit la page que vous utilisez, vous n’avez donc pas besoin de vous appuyer sur un site précis.
- Désactivez le VPN et enregistrez votre IP. Ouvrez la page de vérification IP et notez l'adresse IPv4 publique et, si elle est présente, l'adresse IPv6. Cette valeur constitue la base de toutes les comparaisons ultérieures.
- Allumez votre VPN et comparez les IP. Après avoir vérifié l'indicateur d'achèvement de la connexion sur l'application StageVPN ou l'indicateur vert ON sur l'icône StageVPN pour Chrome, ouvrez à nouveau la même page. IPv4 doit être remplacé par l'adresse de votre serveur VPN.
- Vérifiez votre serveur DNS. Ouvrez la page Test de fuite DNS. Ces pages interrogent des sous-domaines aléatoires, puis affichent le serveur DNS qui a envoyé la requête. Si vous pouvez voir les serveurs de votre opérateur ou de votre routeur, il s'agit d'une fuite DNS.
- Ouvrez chrome://webrtc-internals. La saisie de cette adresse dans la barre d'adresse de Chrome affichera les connexions WebRTC en cours et les adresses des candidats. L'élément apparaîtra si la page de test WebRTC ou la page d'appel vidéo est ouverte dans un autre onglet.
- Vérifiez l'adresse IP du candidat. Si l'adresse du candidat srflx (réflexion du serveur) est la même que l'adresse IP publique d'origine de l'étape 1, il s'agit alors d'une fuite WebRTC. S'il s'agit de l'adresse IP du serveur VPN ou si seuls le nom .local et l'adresse IP privée sont visibles, l'adresse IP publique n'est pas exposée.
- Vérifiez IPv6. Si vous aviez une adresse IPv6 à l'étape 1, activez le VPN et voyez si cette adresse a disparu ou a changé. Si tel est le cas, IPv6 quitte le tunnel. Basculez entre le Wi-Fi et les données mobiles et répétez pour voir si les résultats sont les mêmes après le redémarrage du navigateur.
| Résultats des observations | signification | Cause suivante |
|---|---|---|
| IP du serveur VPN visible sur site | Les communications Web passent par le chemin VPN | Normal, prochaine étape |
| IPv4 a changé, mais IPv6 est l'adresse d'origine | IPv6 quitte le tunnel | Cause 2 |
| Le serveur DNS provient de l'entreprise de télécommunication ou du routeur. | Fuite DNS | Causes 1, 3, 4, 5 |
| Le serveur DNS est un fournisseur DNS public | DNS dans votre configuration VPN ou un DNS sécurisé que vous spécifiez vous-même. | Ne présumez pas qu'il s'agit d'une fuite uniquement basée sur le nom de l'entreprise, vérifiez la cause 4. |
| L'adresse IP publique d'origine est visible dans WebRTC | Fuite WebRTC | Causes 6 et 7 |
| Seuls les noms .local ou les IP privées sont visibles dans WebRTC | L'adresse IP publique n'est pas exposée | généralement normal |
| IP d'origine uniquement immédiatement après le changement de réseau | écart au moment de la transition | Cause 8 |
Les résultats peuvent varier selon le site de test. Il existe des endroits qui affichent uniquement IPv4 et des endroits qui affichent IPv6, et les méthodes de recherche de serveurs DNS sont également différentes. Comparez à plusieurs endroits et en passant à plusieurs réseaux.
Que révèle une requête DNS ?
Les requêtes DNS contiennent des noms de domaine. Le contenu de la page ou les valeurs saisies ne sont pas inclus. DNS est le système de carnet d'adresses d'Internet qui convertit les noms de domaine lus par les humains en adresses IP utilisées par les ordinateurs. Chaque fois que vous saisissez une adresse dans votre navigateur ou qu'une application contacte un serveur, votre appareil demande d'abord au serveur DNS « quelle est l'adresse de ce nom ? Ainsi, en consultant simplement l’historique des requêtes, vous pouvez en savoir beaucoup sur le moment et le service auquel vous avez essayé d’accéder.
- mon appareilApplication/Navigateur
- Requêtes DNS en texte brut
- Wi-Fi publicrouteur de café
- Requêtes DNS en texte brut
- DNS de l'opérateurserveur existant
- Zones pouvant être exposées
- mon appareilApplication/Navigateur
- DNS dans le tunnel
- Wi-Fi publicrouteur de café
- DNS dans le tunnel
- serveur VPNStageVPN
- Requête par IP du serveur VPN
- serveur DNSSpécifier dans la configuration VPN
- Cryptage VPN
Les requêtes DNS traditionnelles sont envoyées au port UDP 53 en clair. Pour compenser cela, DoH (RFC 8484), qui encapsule les requêtes en HTTPS, et DoT (RFC 7858), qui encapsule les requêtes en TLS, ont été créés. Cependant, même si vous utilisez un DNS chiffré, le nom du serveur (SNI) envoyé lors de la connexion à un site via HTTPS peut être visible sur le réseau si le site et le navigateur ne supportent pas ECH (Encrypted Client Hello).
| mode de livraison | Observateur sur le même Wi-Fi | Opérateur Wi-Fi/entreprise de communication | Serveur DNS recevant la requête |
|---|---|---|---|
| DNS brut (texte clair) | peut voir | peut voir | Visible, avec mon IP publique |
| DoH/DoT (DNS crypté) | je ne peux pas voir | Non visible, les adresses des serveurs DNS sont visibles | Visible, avec mon IP publique |
| DNS dans un tunnel VPN | je ne peux pas voir | Non visible, voit seulement qu'il communique avec le serveur VPN | Visible, avec IP du serveur VPN |
| État de la fuite DNS | S'il s'agit de texte brut, vous pouvez le voir. | peut voir | Visible, avec mon IP publique |
Le DNS sécurisé (DoH) et le VPN ont des objectifs différents. DoH chiffre uniquement les requêtes DNS ; le site accède lui-même et les adresses IP que le site voit restent les mêmes. Un VPN crypte l'intégralité de la communication entre votre appareil ou navigateur et le serveur VPN et modifie l'adresse IP vue par les sites. Le mode navigation privée n’arrête pas non plus les fuites. Le mode navigation privée est une fonction qui ne laisse ni historique ni cookies sur l'appareil, et ne modifie pas les requêtes DNS ou les routes WebRTC.
Comment WebRTC détermine-t-il une adresse IP ?
WebRTC trouve sa propre adresse de plusieurs manières pour connecter deux appareils par le chemin le plus court et transmet les résultats au script sur la page Web. WebRTC est une technologie Web standard qui vous permet de passer des appels vidéo, des appels vocaux et des transferts de fichiers sans plug-ins dans votre navigateur. Le processus de collecte d'adresses est appelé ICE (RFC 8445). Même les pages qui ne passent pas d'appels vidéo peuvent démarrer ce processus avec un script.
- Créer un objet de connexionLe script de page Web crée RTCPeerConnection
- Rassembler les candidats locauxVotre navigateur rassemble les adresses des appareils réseau de votre appareil
- Requête STUNDemandez au serveur STUN « à quoi ressemble mon adresse » avec UDP
- Livraison du candidatUne liste de candidats comprenant les adresses publiques fournies par le serveur STUN est livrée sur la page.
| Type de candidat | quelque chose | Informations susceptibles d'être révélées | Protection des navigateurs récents |
|---|---|---|---|
| hôte | Adresse du périphérique réseau de la machine | IP privée (192.168.x, etc.) | Masqué avec un nom .local aléatoire (mDNS), mais peut être vu sur les sites qui ont accordé des autorisations de caméra et de microphone. |
| srflx (réflexion du serveur) | Mon adresse publique vue par le serveur STUN | IP publique, vraie IP si vous contournez le proxy | Peut être restreint par la politique de traitement IP WebRTC |
| relais | TURN Adresse du serveur relais | IP du serveur relais | Si vous utilisez le relais, l'autre partie verra l'adresse du serveur au lieu de votre IP. |
Le problème est la requête STUN à l'étape 3. Les proxys du navigateur transmettent les requêtes Web, mais les communications UDP de WebRTC ne passent pas par le proxy dans les paramètres par défaut du navigateur. L'adresse fournie par le serveur STUN n'est donc pas le serveur proxy, mais mon IP publique d'origine. Les choses sont différentes avec les VPN à l’échelle de l’appareil. Étant donné que toutes les communications UDP, y compris les requêtes STUN, transitent vers le tunnel, l'adresse vue par le serveur STUN est également l'adresse IP du serveur VPN.
Proxy du navigateur et politique par défaut
- Les requêtes Web passent par un proxy
- Les requêtes STUN vont directement à UDP
- La page peut voir la véritable adresse IP publique
Proxy du navigateur et Disable_non_proxied_udp
- Empêcher UDP de passer par proxy
- WebRTC utilise uniquement des chemins proxy
- Certains appels ont des méthodes ou une qualité de connexion différentes
VPN à l'échelle de l'appareil
- Les requêtes STUN passent également par le tunnel.
- Le candidat à l'adresse publique est l'adresse IP du serveur VPN
- La déconnexion et la gestion IPv6 nécessitent une confirmation
Chrome dispose d'une « politique de gestion IP WebRTC » qui détermine quelle adresse WebRTC utilisera, et les extensions peuvent modifier cette valeur. Chaque valeur correspond à quatre méthodes décrites dans la recommandation de gestion des adresses IP WebRTC de l'IETF (RFC 8828).
| valeur politique | mouvement | plage d'exposition |
|---|---|---|
| défaut | Collectez les candidats de tous les appareils du réseau | Le plus large (adresses locales masquées par mDNS) |
| default_public_and_private_interfaces | Utilisez uniquement les appareils sur l'itinéraire par défaut, utilisez des adresses publiques et privées | N'expose pas les adresses d'autres appareils |
| default_public_interface_only | Utilisez uniquement les adresses publiques de la route par défaut | Les adresses privées ne sont pas exposées |
| désactiver_non_proxied_udp | Pas d'UDP via proxy, utilisez TCP via proxy si le proxy ne prend pas en charge UDP | Ne pas exposer les adresses des routes en dehors du proxy |

Solution : Comment vérifier et corriger par cause
La plupart des fuites ont l’une des huit causes suivantes : Ceci est généralement dû à des paramètres qui se chevauchent. Commencez par vérifier le numéro de cause indiqué dans le tableau de diagnostic, et chaque fois que vous en corrigez un, répétez l'étape 6 de l'image ci-dessus pour voir si le résultat a changé. Si vous modifiez plusieurs paramètres à la fois, vous ne saurez pas ce qui a fonctionné.
Cause 1 · Il n'y a pas de serveur DNS dans la configuration VPN ou l'appareil utilise un DNS différent.
vérifier Lorsque le VPN est activé, le test DNS affiche le routeur Wi-Fi ou le serveur DNS de l'opérateur. Vous disposez souvent d'un DNS manuel dans les paramètres Wi-Fi de votre appareil.
résoudre L'application StageVPN inclut un serveur DNS dans la configuration VPN et envoie des requêtes dans le tunnel. Rétablissez le DNS manuel sur automatique dans les paramètres réseau de votre appareil, puis déconnectez-vous et reconnectez-vous au VPN. Si le problème est toujours le même, vérifiez les causes 3 et 5.
Parce que 2 IPv6 sort du tunnel
vérifier IPv4 a été remplacé par l'adresse du serveur VPN, mais IPv6 reste identique à la valeur notée à l'étape 1. Si le VPN tunnelise uniquement IPv4, les requêtes et les communications IPv6 suivront la route d'origine.
résoudre L'application StageVPN est configurée pour envoyer également des communications IPv6 au tunnel (AllowedIPs 0.0.0.0/0, ::/0), il n'est donc généralement pas nécessaire de la désactiver. Si IPv6 apparaît toujours comme il se doit, vérifiez d’abord si une autre application VPN ou les paramètres de l’appareil modifient l’itinéraire. Certains sites de test ne prennent pas en charge IPv6, alors comparez sur plusieurs sites.
Cause 3 · Le système d'exploitation interroge simultanément le DNS de plusieurs périphériques réseau.
vérifier Surtout lors d'une connexion VPN sur un PC Windows, le test DNS affiche à la fois le DNS du VPN et celui de votre opérateur. Cela est dû à une fonctionnalité qui interroge simultanément tous les périphériques réseau, telle que la résolution intelligente de noms multi-hébergements de Windows.
résoudre Gardez votre système d'exploitation et votre logiciel VPN à jour et répétez les tests. Ce phénomène est principalement signalé avec les VPN à l'échelle de l'appareil sur PC, et ne se produit pas de la même manière sur l'application StageVPN sur smartphones et StageVPN pour Chrome sur Chrome en raison de structures différentes.
Cause 4 · Le DNS sécurisé (DoH) est spécifié séparément dans le navigateur ou l'appareil
vérifier Le test DNS montre les serveurs des fournisseurs DNS publics. Dans ce cas, il ne s’agit peut-être pas d’une fuite mais d’un réglage que vous avez vous-même précisé. Si vous disposez d'un VPN à l'échelle de l'appareil, cette requête passera également par le tunnel, mais elle sera reçue par le fournisseur spécifié plutôt que par le DNS dans votre configuration VPN.
résoudre Si tel est le paramètre souhaité, vous pouvez le laisser tel quel. Si vous souhaitez utiliser DNS pour votre configuration VPN, il modifiera automatiquement les paramètres DNS sécurisés de votre navigateur et de votre appareil. Il est important de ne pas présumer qu’il s’agit d’une fuite simplement en regardant le nom de l’entreprise.
Cause 5 · D'autres applications VPN, proxy et de sécurité sont également activées
vérifier Les fonctionnalités réseau d'autres applications VPN, extensions proxy, filtres publicitaires ou programmes de sécurité sont activées en même temps. Les paramètres de l'itinéraire s'écrasent les uns les autres, ce qui entraîne le transfert de certaines requêtes vers l'itinéraire d'origine.
résoudre Allumez-en un seul à la fois. Désactivez les autres applications et extensions, déconnectez et reconnectez StageVPN et répétez l'étape 6. Les paramètres de proxy de Chrome ne peuvent contrôler qu'une seule extension à la fois, donc si une autre extension utilise un proxy, StageVPN pour Chrome ne se connectera pas et vous dira pourquoi.
Cause 6 · Seul le proxy du navigateur est utilisé, mais une communication en dehors du navigateur est attendue
vérifier J'ai activé StageVPN pour Chrome, mais d'autres navigateurs, messageries PC et programmes de messagerie se connectent en utilisant l'adresse IP et le DNS d'origine. Ce n'est pas une fuite, c'est la gamme conçue. L'extension couvre uniquement la communication dans Chrome.
résoudre Si vous devez protéger des programmes en dehors de Chrome, utilisez un VPN qui s'applique à l'ensemble de l'appareil. Sur les smartphones, c'est exactement ce que fait l'application StageVPN. La différence de portée entre les deux méthodes est VPN de navigateur vs VPN d'applicationJe l'ai organisé en .
Cause 7 La politique WebRTC n'est pas appliquée
vérifier J'ai activé StageVPN pour Chrome et je peux voir l'adresse IP publique d'origine dans le test WebRTC ou dans le candidat srflx dans chrome://webrtc-internals. Si une autre politique de gestion d'extension ou d'entreprise/organisation contrôle en premier les paramètres WebRTC, StageVPN pour Chrome ne modifiera pas la politique et la laissera telle quelle.
résoudre Désactivez toutes les autres extensions qui contrôlent les paramètres WebRTC et reconnectez StageVPN pour Chrome. Si la politique de gestion en est la cause, contactez votre administrateur. Pour écrire dans une fenêtre de navigation privée, vous devez activer « Autoriser en mode navigation privée » dans l'écran de gestion des extensions. Lorsqu'elle est désactivée, les communications dans les fenêtres de navigation privée ne passent pas par le proxy.
Cause 8 · Au moment où la connexion VPN est perdue
vérifier L'adresse IP d'origine n'est visible qu'immédiatement après avoir changé de réseau ou quitté le mode veille, et après un certain temps, c'est normal. Pendant la déconnexion, toutes les requêtes et communications empruntent la voie normale.
résoudre Avant d'effectuer tout travail sensible, vérifiez si l'indicateur d'achèvement de connexion de l'application ou l'icône d'extension est allumée. WireGuard, utilisé par l'application StageVPN, ne rétablit pas de tunnel même lors du passage du Wi-Fi au LTE, mais le protocole ne peut pas compenser les déconnexions temporaires du réseau lui-même. La possibilité de bloquer automatiquement les communications lorsque le VPN est déconnecté n'est pas une fonctionnalité fournie par StageVPN. Le principe est Expliquer les principes de WireGuardC'est dans
Comment les applications StageVPN et StageVPN pour Chrome stoppent-elles les fuites ?
L'application StageVPN réduit les fuites en tunnelant toutes les communications, tandis que StageVPN pour Chrome recherche des noms de proxy et ajuste les politiques WebRTC. Puisque l’étendue de la protection est différente, la manière dont elle est gérée est également différente.
| article | Application StageVPN (iPhone·iPad·Android) | StageVPN pour Chrome |
|---|---|---|
| plage de protection | Tous les appareils | Navigateur Chrome |
| Communications envoyées via la route VPN | IPv4·IPv6 Tous (IP autorisées 0.0.0.0/0, ::/0) | Les requêtes Web passent par proxy (hors bandes IP privées et localhost) |
| Requêtes DNS | Transférer dans le tunnel vers le serveur DNS spécifié dans la configuration VPN. | Les requêtes qui transitent par un proxy ne sont pas recherchées par Chrome, mais par le serveur proxy. |
| WebRTC | Toutes les communications UDP passent par le tunnel. | Disable_non_proxied_udp est appliqué lors de la connexion et revient au paramètre d'origine une fois déconnecté. |
| Ce que vous voyez actuellement sur le réseau | Le fait qu'il y ait une communication cryptée avec le serveur VPN et la quantité de données | Recherche de noms d'adresses de serveur proxy, de connexions chiffrées avec le proxy et de communications à partir d'applications extérieures à Chrome |
| Cas qui peuvent ne pas s'appliquer | Pendant que la connexion VPN est perdue, lorsqu'une autre application VPN redirige | Fenêtre de navigation privée avec Autoriser le mode navigation privée désactivé lorsqu'une autre extension ou une autre stratégie de gestion contrôle les paramètres proxy/WebRTC |
| Historique d'accès (93 jours) | Les domaines consultés ne sont pas enregistrés | Le nom d'hôte de destination connecté est enregistré, mais le chemin ou le terme de recherche n'est pas enregistré. |
StageVPN ne vous guide pas à travers un menu distinct de paramètres de protection contre les fuites DNS dans le cadre de ses offres. Le comportement ci-dessus dépend de la configuration VPN par défaut de l'application et de la méthode de connexion de l'extension. Le champ d'application de la prestation est Caractéristiques et étendue de l'offreVous pouvez le vérifier ici.
Aucune fuite signifie que les requêtes et les communications passent par le chemin VPN plutôt que par l'opérateur. Cela ne signifie pas qu’aucun enregistrement ne sera conservé. StageVPN conserve les enregistrements d'accès pendant 93 jours conformément à la loi sur la protection des secrets des communications et n'enregistre pas le contenu des communications. L'article est Accéder à l’avis de stockage des dossiersEh bien, la raison pour laquelle je le révèle est Pourquoi divulguons-nous notre politique de conservation des enregistrements d’accès ?expliqué.

Liste de contrôle de revérification : que vérifiez-vous à nouveau après avoir apporté des modifications ?
Chaque fois que vous corrigez une cause, vérifiez à nouveau les éléments ci-dessous depuis le début. Si tout se passe bien, il n'y a pas de fuite. Si un élément échoue, il retourne sur la carte de cause correspondante.
- Après avoir déconnecté et reconnecté le VPN, j'ai vérifié si l'application indiquait que la connexion était terminée ou si l'icône d'extension était activée.
- Sur la page de vérification IP, soit vous verrez l'adresse du serveur VPN pour IPv4 et IPv6, soit vous ne verrez pas IPv6.
- Le test DNS n'affiche pas le serveur DNS de l'entreprise de télécommunication ou du routeur.
- Le candidat srflx dans chrome://webrtc-internals n'a pas l'adresse IP publique d'origine.
- Les fonctionnalités réseau des autres applications VPN, proxys/extensions VPN et programmes de sécurité sont désactivées.
- Si vous avez défini un DNS manuel ou un DNS sécurisé pour votre appareil et votre navigateur, vous avez vérifié qu'il s'agit du paramètre prévu.
- Votre système d'exploitation, votre navigateur ainsi que les applications et extensions StageVPN sont à jour.
- Même résultat même après avoir basculé entre le Wi-Fi et les données mobiles et redémarré le navigateur.
- Si vous devez protéger des programmes en dehors de Chrome, vous pouvez utiliser un VPN à l'échelle de l'appareil plutôt qu'une extension.
C'est également une bonne idée de déterminer quand une nouvelle inspection est nécessaire. C'est après une mise à jour majeure de votre système d'exploitation ou de votre navigateur, après l'installation d'une nouvelle extension ou application de sécurité, ou avant d'effectuer tout travail sensible sur un réseau auquel vous vous connectez pour la première fois. Si les paramètres sont les mêmes mais que les résultats ont changé, l’une de ces trois choses en est généralement la cause. Une fois pris en main, les 6 étapes du diagnostic peuvent être réalisées en quelques minutes seulement.
Si le problème persiste, organisez le modèle de l'appareil, la version du système d'exploitation et de l'application, l'heure de son apparition et les résultats des tests. support clientVeuillez nous contacter. Veuillez ne pas envoyer votre mot de passe ou votre code de vérification. Les paramètres de l'appareil à vérifier ainsi que la recherche de fuites sont : 10 paramètres de confidentialité du smartphoneEh bien, il existe des risques qui ne peuvent être résolus avec un seul VPN. Ce que les VPN empêchent et ne peuvent pas empêcherEh bien, vos habitudes sur les réseaux publics sont Règles de sécurité du Wi-Fi publicJe l'ai organisé en .
matériel de référence
- RFC 1034 : Noms de domaine — Concepts et fonctionnalités — Structure du DNS et rôle des résolveurs (IETF)
- RFC 8484 : requêtes DNS sur HTTPS (DoH) — Comment chiffrer les requêtes DNS sur HTTPS (IETF)
- RFC 7858 : DNS sur TLS — Comment chiffrer les requêtes DNS avec TLS (IETF)
- RFC 8445 : Établissement de connectivité interactive (ICE) — Types de candidats à la connexion WebRTC et procédures de collecte (IETF)
- RFC 8828 : Exigences de gestion des adresses IP WebRTC — Plage d'adresses que les navigateurs exposent à WebRTC (IETF)
- API chrome.privacy — Valeurs de la politique de gestion IP Chrome WebRTC (Chrome pour les développeurs)
- API chrome.proxy — Paramètres de proxy d'extension, liste de contournement et priorités de contrôle (Chrome pour les développeurs)
- API WebRTC — RTCPeerConnection et le concept de candidats ICE (MDN Web Docs)



