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.

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 :

#fxhelp firefox 28 security issue: webRTC unveiles orig. IP & sends it even if you use a VPN: http://t.co/q6257n280d pic.twitter.com/fs1xPRcM0y

— Abri (@vitalyenbroder) 29 Mars 2014

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).

 
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).