WebRTC, VPN et adresse IP : quand une « faille » vieille d'un an refait surface

WebRTC, VPN et adresse IP : quand une « faille » vieille d’un an refait surface

Ne reste plus que le par-feu d'OpenOffice

Avatar de l'auteur
Sébastien Gavois

Publié dans

Internet

14/02/2015 8 minutes
46

WebRTC, VPN et adresse IP : quand une « faille » vieille d'un an refait surface

Récemment, certains ont évoqué une « faille » de sécurité qui touche WebRTC : si vous utilisez un VPN, il est possible d'obtenir votre adresse IP. Mais, comme nous allons le voir, elle n'est pas nouvelle et faisait déjà parler d'elle il y a plus d'un an. Ce problème avait même été anticipé dès les brouillons de WebRTC de l'époque. Mais aucune protection n'a été mise en place depuis.

WebRTC est un ensemble d'API permettant de gérer des conversations audio/vidéo directement depuis un navigateur, sans plug-in à installer. Chrome et Firefox le prennent nativement en charge, Mozilla l'exploitant par exemple pour son client Hello disponible depuis la mouture 34 de Firefox.

C'est l'histoire d'une « faille » WebRTC qui diffuse votre IP, même derrière un VPN

Problème, WebRTC présente une « faille » qui peut s'avérer relativement gênante pour ceux qui utilisent un VPN et qui souhaitent cacher leur adresse IP d'origine. Elle permet en effet à n'importe quel site web de retrouver cette dernière, et non de s'arrêter à celle du VPN, du moins sous Windows. De très nombreux médias sont revenus sur cette affaire au cours des derniers jours, en évoquant notamment un prototype qui avait été mis en ligne via ce dépôt Github. Pour tester cette « faille », il suffit de se rendre à cette adresse via un VPN pour constater que, dans la liste des adresses IP, celle de votre connexion est bien présente aux côtés de celle du VPN.

IPLeaks VPN webRTC

Cette situation est due au protocole STUN (traversée simple d'UDP à travers du NAT) développé par l'Internet Engineering Task Force (IETF) qui permet à une application de connaitre l'adresse IP réelle de la machine. Il est notamment utilisé dans les clients de type VoIP ainsi que dans le protocole SIP. Il n'est donc pas anormal que WebRTC récupère cette donnée, mais ce qui est plus inquiétant c'est que cela se fasse sans que l'utilisateur en soit informé et sans qu'aucune confirmation ne soit demandée. Mais de fait, cette situation n'a absolument rien de nouveau.

Une « faille » dévoilée il y plus d'un an

En effet, après quelques recherches, on découvre rapidement qu'il existe déjà une extension Chrome permettant de bloquer cette « faille » : WebRTC Block. Détail surprenant, elle est en ligne depuis le 30 mai 2014 et, à l'heure actuelle, toujours en version 1.0. Surprenant pour une « faille » qui faisait parler d'elle fin janvier ? Pas tant que cela puisqu'elle avait en fait déjà été présentée fin mars 2014 par @vitalyenbroder, là encore avec un prototype fonctionnel :

Suite aux papiers de différents médias de fin décembre/début janvier, il a d'ailleurs mis à jour son blog, non sans une certaine dose d'ironie : « Le même problème de fuite VPN/IP a de nouveau été rendu public par un programmeur américain et cela a soulevé beaucoup plus d'intérêt sur Twitter et chez les magazines web. Conclusion : vous devez être américain pour être entendu ? » 

It's not a « faille », it's a « feature » !

Mais nous ne sommes pas encore au bout de nos surprises puisqu'on se rend compte que, dès le mois de janvier 2014 (quelques mois plutôt l'annonce de Vitalyenbroder), le cas d'un VPN utilisé avec WebRTC était remonté via le Bugzilla de Mozilla ainsi que sur les forums de Chromium

Du côté de la fondation au panda roux, l'importance du bulletin est jugée comme « critique », mais uniquement depuis le 31 janvier 2015 (date à laquelle la vague d'articles est sortie dans la presse). Si l'on regarde l'historique, on se rend compte qu'il était seulement considéré comme « normal » auparavant.  De son côté, Chromium a décidé de classer ce problème avec les labels entreprise et vie privée, et non pas sécurité.

Au-delà de ce classement, les réponses des développeurs sont tout aussi intéressantes à étudier. Dans les deux cas, on retrouve en effet une même remarque qui arrive rapidement sur le tapis et qui précise, en substance, que « ce comportement est dû à la conception même de WebRTC ». On retiendra principalement les interventions d'Eric Rescorla, auteur d'un des brouillons de WebRTC et fondateur de RTFM, sur Bugzilla, ainsi que de Justin Uberti, ingénieur logiciel, sur le blog de Chromium. Au travers de leurs commentaires, ils renvoient vers deux documents de l'IETF.

L'IETF avait anticipé ce problème dans les brouillons de WebRTC

Le paragraphe 5.4 du premier document, qui est un brouillon de WebRTC, précise clairement les choses (nous sommes début 2014) : « Un effet secondaire du fonctionnement du ICE [NDLR : Interactive Connectivity Establishment] est que la machine distante connait l'adresse IP de la première, ce qui donne de grandes quantités d'informations sur la géolocalisation. Cela a des conséquences néfastes sur la vie privée dans certaines situations. »

Le second document est un autre brouillon de WebRTC et, à la section 4.2.4 dédiée à la localisation d'une adresse IP, on trouve le commentaire suivant : « En fonctionnement normal, les sites connaissent les adresses IP, mais elle peut être cachée via des services comme Tor ou un VPN. Cependant, parce que les sites peuvent obtenir l'adresse IP du navigateur, cela donne aux sites un moyen de récupérer des renseignements sur le réseau de l'utilisateur, même s'il est derrière un VPN afin de masquer son adresse IP. » Il est ensuite précisé qu'il « serait souhaitable que les implémentations proposent des paramètres qui suppriment toutes les adresses IP qui ne sont pas celles du VPN si l'utilisateur exploite certains types de VPN, et en particulier des systèmes de protection de la vie privée comme Tor ».

Des recommandations sont également formulées afin de proposer des protections pour protéger l'adresse IP native dans le cas de l'utilisation d'un VPN. L'API de WebRTC pourrait par exemple fournir une solution afin de permettre à JavaScript de supprimer une demande de connexion tant que l'utilisateur n'a pas décidé de répondre à l'appel. Il est également question de restreindre les connexions aux adresses passant par un serveur TURN (Traversal Using Relays around NAT), ce qui aurait pour effet de protéger l'adresse IP native. Des recommandations qui ne semblent pas avoir été spécialement suivies par Mozilla et Google. Par contre, WebRTC est bien désactivé par défaut dans dans Tor Browser (qui exploite Firefox).

 WebRTCWebRTC
La différence entre STUN et TURN

Au final, comment se protéger de cette « faille » liée à WebRTC avec Chrome et Firefox ? 

Quoi qu'il en soit, il règne désormais une ambiance tendue avec une certaine incompréhension entre les deux camps. D'un côté, ceux qui pensent qu'il s'agit d'une « fonctionnalité » liée à WebRTC, qui nécessiterait tout de même des ajustements afin de mieux protéger la vie privée ou au moins donner plus d'information et de possibilités à l'utilisateur. De l'autre, et ceux qui estiment qu'il est question d'une importante faille de sécurité qui doit être corrigée.

Notez que pour vous protéger de ce genre de mésaventure, dans Firefox il est possible de désactiver WebRTC par défaut. Pour cela, il faut vous rendre dans « about:config » puis désactiver « media.peerconnection.enabled ». Cette manipulation n'est pas possible pour l'instant sur Chrome et il faudra donc passer par l'extension WebRTC Block afin de désactiver ce service. Le problème semblerait ne pas apparaitre lorsque le VPN est configuré sur une box ou un routeur et pas directement sur l'ordinateur sous Windows.

Avec l'ampleur médiatique des deux semaines précédentes, il sera intéressant de voir comment vont régir les deux navigateurs par rapport aux deux camps et aux différentes possibilités d'évolution. La situation restera-t-elle la même, désactiveront-ils par défaut WebRTC ou bien demanderont-ils une validation à l'utilisateur avant de transmettre l'adresse IP ? La question reste pour le moment ouverte.

Notez néanmoins que cette dernière possibilité ne semble pas spécialement plaire à Google qui indique, par la voix de l'un de ses développeurs avoir « considéré cette option, mais je ne pense finalement pas qu'introduire une action de l'utilisateur soit logique. Ce n'est pas une demande qui sera bien comprise ("voulez-vous que cette application puisse dévoiler vos différentes interfaces réseau ? ") ». Après, rien n'empêche de modifier le message afin de mettre un avertissement pour ceux qui utilisent un VPN, avec un lien vers des explications détaillées si besoin.

On pourrait par exemple imaginer un système qui fonctionne comme les demandes de géolocalisation qui peuvent être autorisées pour certains sites mais pas pour d'autres (comme lorsque les sites de presse veulent vous géolocaliser).

46

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

C'est l'histoire d'une « faille » WebRTC qui diffuse votre IP, même derrière un VPN

Une « faille » dévoilée il y plus d'un an

It's not a « faille », it's a « feature » !

L'IETF avait anticipé ce problème dans les brouillons de WebRTC

Au final, comment se protéger de cette « faille » liée à WebRTC avec Chrome et Firefox ? 

Commentaires (46)


Il y a un truc que je ne comprends pas… Pourquoi la requête STUN ne rentre pas dans le VPN ? Ne s’agirait-il pas d’un problème d’implémentation du client VPN ? STUN utilise UDP et TCP sur le port 3478 si je comprends bien la RFC, je ne vois pas de souci pour un passage par un VPN si celui-ci s’ajoute proprement dans la table de routage du système.



Dans le cas d’un proxy, c’est différent et le navigateur devrait afficher un message avant toute requête STUN.


De ce que j’en ai compris c’est surtout un problème de configuration du client VPN (si il n’y a pas de route vers la passerelle “publique” et uniquement vers la passerelle VPN, le test ne fonctionne pas).


Petite astuce pour Firefox, aller sur about:config, puis double cliquer sur media.peerconnection.enabled pour désactiver la fonction.

Plus de risques de fuite.








eyce a écrit :



De ce que j’en ai compris c’est surtout un problème de configuration du client VPN (si il n’y a pas de route vers la passerelle “publique” et uniquement vers la passerelle VPN, le test ne fonctionne pas).





Ok ça confirmerait mon avis.







bingo.crepuscule a écrit :



Petite astuce pour Firefox, aller sur about:config, puis double cliquer sur media.peerconnection.enabled pour désactiver la fonction.

Plus de risques de fuite.





Je n’utilise pas Firefox, par contre l’explication technique du problème m’intéresse et les articles sur la toile occultent cela pour préférer le sensationnel (“une faille dans Chrome et Firefox !” est plus vendeur que “les clients VPN sont pourris”). NXi essaie d’aller plus loin dans l’analyse mais ne parle pas de la responsabilité du client VPN…





Notez que pour vous protéger de ce genre de mésaventure, dans Firefox il

est possible de désactiver WebRTC par défaut. Pour cela, il faut

vous rendre dans « about:config » puis désactiver «

media.peerconnection.enabled ».



Merci pour la manip, que je viens d’effectuer. <img data-src=" />


Je trouve que le ton est un peu anxiogene.





  1. Le probleme n’est lié qu’a des personnes qui utiliserai un VPN pour masquer leur identitié (ce qui doit faire 0.1% du surf)



  2. Le problème livre une ip, il ne permet aucun accès special.



    Je reste persuadé que les navigateur grand public ne cachent rien de leur utilisateur, meme connecté via un vpn.


&gt;Au final, comment se protéger de cette « faille » liée à WebRTC avec Chrome et Firefox ?



En voilà une partie qu’elle est intéressante <img data-src=" />


Pareil je ne comprends pas comment ca bypasse le vpn , pas logique


J’ai pas encore tout bien compris, je suis donc peut-être complètement à côté de la plaque :(



Mais j’ai juste l’impression que WebRTC donne l’IP système, ce qui dans le cas d’une IP locale non-routable et naté comme on a en générale derrière une box (192.168…, ou 10….), n’a aucun intérêt.



&nbsp;Je n’utilise pas de VPN, mais lorsque je vais sur l’adresse de test de la news : https://diafygi.github.io/webrtc-ips/

Il m’affiche (en second) l’IP publique de ma box, qui aurai pu être celle d’un VPN, jusqu’ici c’est normal.

Et l’IP locale donnée par WebRTC : 192.168.1.2 Bon courage pour me géolocaliser avec ça <img data-src=" />

Et je n’ai pas l’impression que webRTC ait pu donner autre chose si j’avais été derrière un VPN.

&nbsp;

Si par contre mon PC avait directement une IP publique (IP v6, box en mode bridge) et que j’utilisais un VPN, là il y aurait effectivement un problème.



Pourquoi WebRTC donne l’IP locale, alors que j’ai l’impression que ça ne sert à rien si on est naté, et qu’on ne le souhaite pas lorsque l’on est derrière un VPN ? Aucune idée.


Justement le problème est que ça donne souvent l’IP du NAT de box et non pas l’IP publique du serveur VPN, ce qui ressemble plutôt à un problème de l’implémentation des clients VPN (cf. eyce).


Effectivement ça me donne aussi mes IP locales, bien d’alarmant sur ce point.



Par contre j’ai ensuite activé un VPN maison (OpenVPN, et avec route qui envoie tout le trafic dedans), et là ça m’a donné mon IP du VPN (normal) mais au-dessous j’ai aussi mon IP WAN de ma Box… et là je comprends pas.


Je viens de tester et je me suis documenté sur le sujet, le problème n’est absolument pas du coté du protocole lié à WebRTC.

Sous Linux il n’y a aucun problème, l’IP publique n’est pas dévoilé, uniquement l’IP du VPN.

Le problème est juste apparemment avec certaine implémentation de VPN sous Windows…


benjarobin: non, le problème ne vient pas de windows… Mais de l’article, qui préfère le sensationnalisme à l’exactitude.



Le code permet de récupérer toutes les IP locales d’un PC. Donc dans le cas (majoritaire) où le PC n’a pas d’IP publique attribuée, on ne voit que l’IP du VPN… Testé à l’instant:



Your local IP addresses:





  • 172.19.0.14

  • 192.168.0.85





    Your public IP addresses:



  • 158.XXX.XX.XX





    172.19.0.14 =&gt; mon IP locale sur le réseau du VPN

    192.168.0.85 =&gt; mon IP locale sur mon réseau local

    158.XXX =&gt; l’IP publique de mon VPN.



    On ne voit pas l’IP publique de ma box, puisque faisant office de routeur, elle n’attribue pas d’IP publique à mon PC. L’auteur de l’article a certainement une box en mode bridge (ou alors l’IP vient de leaks DNS qui n’ont rien à voir avec webRTC).



    C’est dommage de voir de telles exactitudes dans un article payant, censé représenter les articles où l’analyse est poussée jusqu’au bout…


Tu me rassures, j’ai eu la flemme de tester avec Windows. Donc en résumé plein de sites ne disent que des propos non vérifiés… :-(

Je suis vraiment (une nouvelle fois) déçu par Nextinpact


Je reproduit pas le bug&nbsp; non plus (Firefox 35, Gentoo, OpenVPN via NetworkManager)



&nbsp;Your local IP addresses:





  • 192.168.0.1

  • 10.0.0.1

  • 10.211.1.1





    Your public IP addresses:



  • 197.211.254.4 &lt;- c’est bien l’IP du VPN





    Des VPN pour tester :http://www.vpngate.net/en/



    S’il faut vraiment avoir son IP publique configuré sur le PC ça réduit quand-même beaucoup l’importance du problème avec la généralisation des box.


En effet, je pense que parler d’un problème de sécurité lié au navigateur est se cacher de l’origine réel de l’erreur. Il s’agit bien d’un problème de configuration ou de fonctionnement du VPN qui ne route pas correctement tous les trafics à travers lui.



Une bonne configuration donnera les adresses locales (réseau en 192 ou 10 chez moi, y compris le réseau très local entre les différentes machines virtuelles) et l’adresse de sortie du VPN. Pas d’autres.



Parlons donc de problèmes de configuration par défaut des VPN plutôt que d’une faille dans le WebRTC.



Si vous faîtes partie de ceux qui souhaitent ce cacher pour surfer et que vous êtes plus que paranoïaques, la solution reste une machine virtuel dédiée et réinitialisée très régulièrement, avec son VPN configuré et aucune communication avec le reste du PC et un Torbrowser. Cela devrait vous abriter.&nbsp; Mais il faut avoir plus qu’à ce protéger de google pour en arriver à de tels extrémités.


Je ne comprends pas, j’ai pourtant mon OpenVPN configuré correctement et avec les bonnes routes, tout le trafic doit passer dedans, donc je vois pas comment la page web m’affiche à la fois mon IP publique de VPN et celle publique de ma Box…


Je comprenais pas avant de lire ma fin de l’article pourquoi je n’était pas touché. Je suis chez Free et je veux du débit alors j’ai un vpn up en default gw sur mon pi …



Sinon sympa comme chose. L’ensemble des vpn est mis en cause? Car du vpn entreprise avec firewal j’ai des doutes


Tu ne serais pas en mode bridge ? Es tu derrière un routeur avec un réseau local ?


Tu pourrais nous poster ta table de routage ? (Route print dans une invite de commande pour Windows)


Par contre pour ce qui est de l’IPv6 je pense que si on a obtenu une IPv6 globale depuis la BOX, alors si le protocole fonctionne aussi en IPv6 alors l’IP publique en IPv6 est surement dévoilée.


pas de souci de mon coté non plus (Chrome)



IP publique: celle de mon VPN (normal)



IP locales:

-&nbsp;celle sur mon routeur a la maison (192.168.1.53)




  • celle en interne sur mon serveur vpn (10.0.1.4)


Aucun soucis chez moi sous Chrome et firefox avec windows 7



Your local IP addresses:



10.10.10.103

192.168.0.10

192.168.56.1



Your public IP addresses:



66.45.243.198



10.10.10.103 &lt;= IP local VPN

66.45.243.198 &lt;= IP public VPN



Ou est la vérité dans l’histoire donc ? Y a t’il un cas de preuve concret ou l’ip publique réel est révélé ?


Hello,&nbsp;Justement je viens de faire le test, et mon ip réelle est révélée.&nbsp;

&nbsp;&nbsp;

J’ai testé sous mac avec le client intégré, connecté à mon serveur L2TP.

&nbsp;

Your public IP addresses:

&nbsp;90.61 xxx &lt;= VPN

&nbsp;83.114 &lt;= Réelle



Du coup soit c’est le client, soit c’est ma config, soit c’est Apple&nbsp;<img data-src=" />


Si le problème existe sur Mac j’ai du mal a croire qu’il n’existe pas sur Linux du coup.



Je pense que la config du VPN est clairement en cause, toute plateforme confondu. J’aurai donc tendance a dire que y’a pas de faille quand même.








fidjick a écrit :



Hello,&nbsp;Justement je viens de faire le test, et mon ip réelle est révélée.&nbsp;

&nbsp;&nbsp;

J’ai testé sous mac avec le client intégré, connecté à mon serveur L2TP.

&nbsp;

Your public IP addresses:

&nbsp;90.61 xxx &lt;= VPN

&nbsp;83.114 &lt;= Réelle



Du coup soit c’est le client, soit c’est ma config, soit c’est Apple&nbsp;<img data-src=" />





Un ptit ifconfig pour voir quelles ip sont associés à tes interfaces ?









benjarobin a écrit :



Tu ne serais pas en mode bridge ? Es tu derrière un routeur avec un réseau local ?





Non pas de mode bridge, j’ai une Bbox FTTLA toute simple (mode routeur).







f-heure-7 a écrit :



Tu pourrais nous poster ta table de routage ? (Route print dans une invite de commande pour Windows)





Bingo ça vient de là :

Par défaut mon OpenVPN maison m’ajoute bien une route qui force à tout passer à travers le VPN, avec une métrique plus petite que la route vers ma Box, donc le VPN est prioritaire (tout le temps).

Et donc je ne sais pas comment mais WebRTC arrive malgré tout à connaître mon IP WAN, peut-être en passant quand même par le chemin non prioritaire.

Je viens d’ajouter dans mon script de lancement de VPN une commande qui supprime ma route par défaut vers ma Box, car de toute façon OpenVPN m’en crée une qui dirige uniquement les paquets prévus pour l’IP externe de mon VPN vers l’IP de ma Box.



Ainsi, désormais, il n’y a qu’un seul itinéraire possible pour les autres IP, c’est à dire tout l’extérieur, ça passe par le VPN.

Une fois que j’ai supprimé la route “inutile” le site web ne m’affiche plus qu’une seule IP externe, celle du VPN.



Est-ce que quelqu’un veut plus d’infos avec les tables de routages complètes avant et après ? (ça me prendrait du temps à masquer en partie certaines IP, donc je préfère être sûr que quelqu’un ait besoin…)



Je ne vois pas en quoi on vient nous accuser de sensationnalisme, alors que l’on a justement pris le temps de remonter à la première déclaration de ce problème, en précisant justement le fait que ce n’était pas à proprement parlé une faille. &nbsp;



Le fait que tu ne sois pas touché dans ton cas, du fait de ta configuration, ne change rien à la problématique de départ et au fait qu’il y a bien un souci : certains utilisateurs qui utilisent un VPN notamment pour masquer leur IP peuvent voir celle-ci dévoilée via WebRTC, et donc récupérée par n’importe quelle page web, sans en être alerté. Toute la “littérature” sur le sujet ne tombe pas du ciel (voir les nombreux liens de l’article), et l’on a vérifié qu’il y avait bien un souci avant de nous-même nous intéresser à la question.



Comme on le précise dans le papier, des protections pour éviter ce genre de cas auraient pu/du être mises en place directement au sein du protocole/des API, cela n’a pas été fait. Les premières remontées datent de plus d’un an, cela a refait du bruit récemment (ce qui nous a poussé à creuser sur le sujet), on a donc fait le point et l’on indique comment éviter le problème en attendant que cela soit pris en compte à la racine.


C’est le correcteur orthographique de son navigateur qui a malencontreusement intervertit le mot “professionnalisme” avec le mot “sensationnalisme” <img data-src=" />


Merci pour le partage ! <img data-src=" />



A mon avis, Firefox se binde sur chaque interface IP disponible pour faire ses requêtes STUN. Vu que les systèmes d’exploitation pour Workstation ne font pas de routage entre interfaces par défaut, le choix de la meilleure route doit se faire par interface source.


Perso avec OpenVPN sous windows, mon IP de mon FAI est bien révélée de base.



En rajoutant ces lignes dans mon fichier de config d’OpenVPN, plus de problèmes:

script-security 2 system

route-up “route delete 0.0.0.0/0”



Par contre, j’ai du rajouter un script pour récuperer la route par défaut lorsque je veux déco mon VPN. Dans le fichier de config d’OpenVPN, j’ai rajouté:

down “down.bat”



Et dans le fichier down.bat:

route add 0.0.0.0/0 192.168.1.1



&nbsp;


Ce qui confirme bien que le problème vient majoritairement de la configuration du VPN. Cela n’empêche pas WebRTC d’être un révélateur, mais est-ce à lui de palier à la mauvaise configuration du VPN ? Le mieux à faire étant de le désactiver, ou de vérifier la configuration de son client VPN.



A noter que si WebRTC est capable de retrouver cela, il est possible que d’autres codes exécutés côté PC en soient capable. Si l’on veut rester protégé il convient que le javascript soit interdit ou pour le moins limité et l’utilisation d’applet java est certainement un gros risque de découverte. Toutes introduction de code malicieux aussi. D’où la recommandation de travailler dans une image de VM qui sera réinitialisée à chaque utilisation.



Il faudrait testé sur un VPN mal configuré, mais je pense que si le serveur de VM est configuré en NAT c’est l’adresse privée du PC qui sera révélée et pas l’adresse du routeur. Essai a faire.


C’est un serveur STUN qui renvoie l’adresse IP publique vue. Tu peux faire autant de NAT que tu veux, il verra forcément l’IP publique de sortie sur Internet (le dernier NAT).



Si tu veux te protéger via un VPN, il faut filtrer le trafic. Dans ce cas, seul du trafic VPN doit sortir sur Internet, donc il faut supprimer les routes non liées au VPN sur le client et rejeter le trafic du client qui va vers autre chose que le bon port du serveur VPN.


J’ai fini par utiliser Wireshark pour être sûr de comprendre ce qui se passe. Et tu as tout à fait raison. Firefox va lancer une requête STUN sur chaque route “par défaut”. Il ne va pas lancer qu’une seule requête STUN sur la route par défaut la plus prioritaire (avec le plus petit métric). Firefox essaye tous les chemins…



Donc c’est bien un problème de configuration du VPN (le test est fait avec le client officiel de OpenVPN) car la route par défaut vers la BOX aurait du être supprimé.








GentooUser a écrit :



Je reproduit pas le bug&nbsp; non plus (Firefox 35, Gentoo, OpenVPN via NetworkManager)



&nbsp;Your local IP addresses:

192.168.0.110.0.0.110.211.1.1



      Your public IP addresses:    

197.211.254.4 &lt;- c'est bien l'IP du VPN



Des VPN pour tester :http://www.vpngate.net/en/



S’il faut vraiment avoir son IP publique configuré sur le PC ça réduit quand-même beaucoup l’importance du problème avec la généralisation des box.





En fait il suffit d’avoir un problème de configuration de la passerelle par défaut (route 0.0.0.0) sur laquelle la métrique pourrait être foireuse.

Pour être tranquille, il faut que le VPN supprime la route 0.0.0.0 des interfaces réseaux pour ajouter la route uniquement vers le serveur VPN, puis ensuite qu’il recréé la route 0.0.0.0 sur le VPN. Une fois ceci fait, il n’y a aucune fuite possible.



<img data-src=" /> Rien de tel que Wireshark. <img data-src=" />



Merci <img data-src=" />


Sur les système de daube : aucun doute .



Sur un vrai os, conçu proprement :






         Demo for:   



https://github.com/diafygi/webrtc-ips






         This demo secretly makes requests to STUN servers that can log your   

request. These requests do not show up in developer consoles and

cannot be blocked by browser plugins (AdBlock, Ghostery, etc.).






     Your local IP addresses:   






     Your public IP addresses:   







  • 27.100.17.64




Dans mon cas, la fonction permet seulement de connaître l’adresse de mon réseau local, donc aucun intérêt.

Mon VPN reste bel et bien invisible. De toute façon, je suis plus proche d’un FAI personnel que du VPN classique (4 liens de transit fournis par Orange - serveur hébergé chez OVH - IP achetée).



Il faut simplement avoir un VPN dont le client est monté sur un routeur (au hasard pfSense). si on ne dispose pas d’un routeur physique, une VM monté sur le client peux très bien faire l’affaire.

&nbsp;


Voilà, idem.



Je n’ai pas intégré cette commande à OpenVPN, mais le résultat et la “correction” sont les mêmes ;)


Testé à l’instant avec Firefox et Chrome sur Windows 7 et mon serveur VPN PPTP (Synology)



Your local IP addresses:

10.0.0.1 (IP local VPN)

172.17.1.40 (IP local)

169.254.128.201 (seconde carte réseau en APIPA)

Your public IP addresses:

82.x.x.x (IP public de mon serveur VPN)



&nbsp;A aucun moment l’IP public de ma connexion est dévoilée. Effectivement la faille est présente si la box est en mode bridge (ou alors sur les VPN utilisant d’autres protocoles (L2TP/VPN SSL.. )


Ca c’est intéressant. Tu as pu faire quelques tests avec différents systèmes de VPN sous Windows ? Ou connais du monde l’ayant fait ?


Non, je n’ai testé qu’avec OpenVPN. Mais le problème sera toujours le même (s’il est présent) : 2 routes par défaut qu lieu d’une.


C’est vrai qu’OpenVPN pourrait supprimer la route inutile une fois lancé… puis la remettre quand il se coupe.



A défaut, le script fonctionne bien (dont pour lomac).


Ca fonctionne bien si ta passerelle a toujours la même IP.

Quand tu

utilises un VPN pour te protéger sur des wifi publics, ou pour

contourner des “optimisations” d’opérateurs téléphoniques quand tu fais

du tethering, il faut être capable de retrouver l’adresse de la

passerelle quand tu coupes le VPN. Ce n’est pas trivial (mais faisable par script appelé par le fichier de conf).



OpenVPN n’a pas à supprimer la route “inutile” (comment fait il pour savoir qu’elle est inutile ?) une fois lancé, il ne fait pas de routage. Les modifications de la table de routage sont faites par l’utilisateur (ou son admin) dans le fichier de conf qu’il a rédigé. Si il veut supprimer la route existante, il peut.

A la rigueur tu peux leur demander de fournir des fichiers d’exemple qui correspondent à ce type de besoin, mais ça ne corrigera pas le “problème”.


Pourquoi alors sous Linux la route par défaut est bien supprimé et bien restauré à la déconnexion ?

Et non les modifications de la table de routage sont faites aussi automatiquement.


Chez moi, sous linux comme sous windows, avec une conf openvpn telle que tu la trouves dans les docs openvpn ou dans 99% des tutos que remonte google pour faire passer le trafic par le vpn (i.e. un push “redirect-gateway def1 bypass-dhcp” côté serveur, et rien concernant le routage dans la conf du client), on conserve les 2 routes :



route -n

Table de routage IP du noyau

Destination&nbsp;&nbsp;&nbsp;&nbsp; Passerelle&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Genmask&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Indic Metric Ref&nbsp;&nbsp;&nbsp; Use Iface

0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 10.8.0.5&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 128.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UG&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 tun0

0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 192.168.1.254&nbsp;&nbsp; 0.0.0.0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; UG&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 0 eth0

[…]



Les add dans la table de routage sont le résultat du “redirect-gateway def1 bypass-dhcp”, rien n’est fait automatiquement.

Si tu as des modifs sur tes routes préexistantes, c’est qu’elles sont indiquées dans la conf.