La Fibre

Télécom => Réseau => reseau TCP/IP / Fonctionnement des réseaux => Discussion démarrée par: corrector le 03 février 2015 à 01:30:49

Titre: Faille RTCPeerConnection
Posté par: corrector le 03 février 2015 à 01:30:49
Google Chrome WebRTC IP Address Leakage

Vulnerability Details:
Chrome has a vulnerability whereby internal IP addresses of users can be leaked using Javascript alone without notifying the user.

Affected Versions:
Chrome Version: Version 31.0.1650.63 m + Version 32.0.1700.72 beta-m Stable + Version 34.0.1781.0 Canary
Operating System: Windows 7 Service Pack 1

Reproduction Case:
The following can be executed in the Chrome console to reproduce the test case. A self-contained HTML file has also been attached.

// create a new peer connection - dont need any stun servers for this attack to work
// adding a stun server provides the external ip address of the user as well (see HTML example)
var peer = new webkitRTCPeerConnection(null);

// create an offer object before any streams are added
// this is important because getUserMedia() requires explicit user permission
peer.createOffer(function(sdp) {
   peer.setLocalDescription(sdp, function() {
      // there seems to be a bug in the async call where the callback is called before the localDescription property has been set
      // setTimeout provides some time for the async call to finish
      setTimeout(function() {
         var sdp = peer.localDescription.sdp;
         console.log(sdp);
      }, 100);
   });
}, function(err) {
   console.error(err);
}, {});


https://code.google.com/p/chromium/issues/detail?id=333752

COMMENTAIRE

Ce n'est pas une faille DANS l'implèmentation ou dans l'API... c'est l'API qui est en soit une faille quand l'adresse IP locale n'est pas l'adresse IP visible de l'extérieur, c'est à dire dès qu'on passe par un proxy ou un NAT.

Ce commentaire sous le bug est hallucinant :

#7 juberti@chromium.org
We considered this, but in the end I don't think that introducing user action makes sense. It's not a permission that is well understood ("do you want this application to enumerate your network interfaces?")

With the move to IPv6, the notion of NATed addresses goes away, so any concerns here around exposing internal addresses to applications are only significant in the short term.

If the main concern is the enumeration of all interfaces, one option could be to only return the interface that has the default route. This might complicate wwan/wlan handover scenarios though.

'tain, un dév de Chromium n'a absolument AUCUNE idée de ce qu'est le Monde réel!

J'y crois pas... je suis très déçu par Chromium, là.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 02:07:43
      Users can safely visit arbitrary web sites and execute scripts
      provided by those sites.

   It is important to realize that this includes sites hosting arbitrary
   malicious scripts.
  The motivation for this requirement is simple:
   it is trivial for attackers to divert users to sites of their choice.
   For instance, an attacker can purchase display advertisements which
   direct the user (either automatically or via user clicking) to their
   site, at which point the browser will execute the attacker's scripts.
   Thus, it is important that it be safe to view arbitrarily malicious
   pages.  Of course, browsers inevitably have bugs which cause them to
   fall short of this goal, but any new WebRTC functionality must be
   designed with the intent to meet this standard
.  The remainder of
   this section provides more background on the existing Web security
   model.

Source : http://tools.ietf.org/id/draft-ietf-rtcweb-security-05.txt

Cela devrait aller sans dire, mais ça va mieux en le disant.

Mais ça :

5.4.  IP Location Privacy

   A side effect of the default ICE behavior is that the peer learns
   one's IP address, which leaks large amounts of location information.

   This has negative privacy consequences in some circumstances.  The
   API requirements in this section are intended to mitigate this issue.
   Note that these requirements are NOT intended to protect the user's
   IP address from a malicious site.

Source : http://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-07#section-5.4

On croit rêver...
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 02:24:10
Citer
#21 jorg...@chromium.org
Removing from security queue, implemented as per the spec.

C'est conforme à la spec DONC c'est pas une faille.

Les dévs Chromium sont des très gros connards ou les dévs Chromium sont des énormes connards?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 03:36:11
Exemple utilisant un service externe :

https://github.com/diafygi/webrtc-ips
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 03 février 2015 à 07:28:04
C'est conforme à la spec DONC c'est pas une faille.

Les dévs Chromium sont des cons ou les dévs Chromium sont des bouffons?

essais de comprendre comment ils fonctionnent avant de les insulter?

deja tu cites un extrais , incomplet et hors contexte. relis le et cites le entier y compris quand ils enlevent/ajoutent des labels.

car il faut comprendre comment fonctionne le 'triage' et les labels (le but est de déterminer le type de bug et qui ensuite doit le traiter et avec quelle priorité). Ajouter un label particulier notifie les personnes en charge de ce domaine ce qui déclenchent leur interventions.

Suites aux différentes interventions dans le suivi du bug ils en sont arriver a décider que , pour le moment, ce n'est pas un probleme de sécurité mais un probleme de privacy/entreprise. Ce n'est pas tout a fait la même chose, la même importance/urgence et ensuite ce n'est pas pris en charge, suivi et superviser par les mêmes personnes.

Et ils n'ont pas tord car c'est avant tout un probleme de privacy/entreprise si on se donne 2 minutes pour réfléchir au probleme.
D'autant que les auteurs de WebRTC sont au courant du 'probleme'.

Franchement beaucoup d'excitation pour pas grand chose.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 08:24:25
essais de comprendre comment ils fonctionnent avant de les insulter?
Non, je n'essaie pas de faire ça, je m'en tape. Comme tous les gens censés.

deja tu cites un extrais , incomplet et hors contexte.
Le coup du contexte, ça faisait longtemps...

Le contexte, c'est magique.

Une connerie dans un contexte ça devient une non-connerie.

Et ils n'ont pas tord car c'est avant tout un probleme de privacy/entreprise si on se donne 2 minutes pour réfléchir au probleme.
D'autant que les auteurs de WebRTC sont au courant du 'probleme'.
Alors si ils sont au courant de cette monstrueuse faille de sécurité, c'est bon.

Ce que j'ai indiqué concernant les dév Chromium ne s'applique pas qu'à eux, hein...

Franchement beaucoup d'excitation pour pas grand chose.
La charte m'interdit de caractériser ta réponse comme il faudrait.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Polynesia le 03 février 2015 à 11:48:51
Intéressant sauf encore aux non anglophones comme moi... :'(
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 03 février 2015 à 14:51:03
en français:

La mise en oeuvre actuelle de WebRTC dans Chrome et Firefox permet avec du code javascript d'obtenir les @ IP privés (=LAN) du navigateur sans l'accord explicite de l'utilisateur.
exemple ici: http://net.ipcalf.com/ (chez moi ca affiche 192.168.1.42 et d'autres IP locales de mon poste).

C'est un souci pour certains et pas pour d'autres (dans mon cas rien a battre qu'un site puisse obtenir mon IP privée), donc certains caractérisent ça de 'faille de sécurité' alors que d'autre catégorisent ça comme étant un probleme de 'confidentialité/vie privée' (privacy) ou d' 'entreprise' (en gros = ça doit être laissé a l'appréciation de la politique de l'entreprise donc "réglable" par un administrateur). Ca peut être un souci avec certaines configurations de VPN et des IP publics LAN (= probleme d'entreprise et pas grand public).

Chrome et Firefox respectent les specs de la norme WebRTC et se doivent donc de fonctionner comme cela. Ils ont donc décider , par défaut, d'autoriser ce comportement plutôt que de le bloquer (opt-in par défaut).

Ceux qui veulent empêcher ce fonctionnement peuvent, avec Chrome, installer cette extension (https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm) pour bloquer. Dans Firefox ca se fait directement dans les flags (about:config) avec en désactivant "media.peerconnection.enabled".

Le débat si c'est une faille de sécurité ou juste un probleme de privacy/entreprise n'est bien sur pas tranché et ne le sera peut-être jamais mais ce débat n'a rien à  faire dans le bugtracker de Chrome et n'a pas a le polluer (ca n'est pas non plus aux devs de Chrome de trancher la question mais plus a l'IETF et/ou ceux qui mettent au point les specs de WebRTC). C'est un peu le même débat qu'avec le "user-agent" qui communique l'OS, sa version, le nom du navigateur, sa version a tout les sites qu'on consulte. Personne ne parle de faille de sécurité la ... sauf les extrémistes parano ;) Et avec IPv6 la question ne se pose même plus (sauf cas tordus).


Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: PacOrly le 03 février 2015 à 15:32:07
Merci pour la traduction...
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 15:43:42
C'est un souci pour certains et pas pour d'autres (dans mon cas rien a battre qu'un site puisse obtenir mon IP privée), donc certains caractérisent ça de 'faille de sécurité' alors que d'autre catégorisent ça comme étant un probleme de 'confidentialité/vie privée' (privacy) ou d' 'entreprise' (en gros = ça doit être laissé a l'appréciation de la politique de l'entreprise donc "réglable" par un administrateur).
Pour la plupart des gens c'est une faille de sécurité.

Pour moi c'est très clairement une faille, donc le débat est clos. Si même moi je dis que c'est une faille alors c'est une faille merci au revoir.

Chrome et Firefox respectent les specs de la norme WebRTC et se doivent donc
NON

Il doivent rien du tout à la norme et tout aux utilisateurs, et énormèment d'utilisateurs n'aiment pas ça.

Et l'IP privée ne servira que très très rarement en pratique.

Les normes, c'est des mecs qui s'autorisent à penser des trucs, hein. C'est souvent remplis de conneries, que les connards péteux croient devoir suivre (les très gros connards qui décident pour Firefox, ou pour GNU C). Cela me met hors de moi.

Ces mecs se branlottent avec la norme et crache à la gueule des utilisateurs.

Moi j'ai participé à des normalisations, je sais comment ça se passe, déjà la moitié des mecs ne bittent RIEN à ce qui se trament, souvent il y a 3 mecs qui comprennent les subtilités et les autres qui font confiance. C'est le principe même des comités, la plupart des mecs (et les nanas, hein) font de la figuration.

de fonctionner comme cela. Ils ont donc décider , par défaut, d'autoriser ce comportement plutôt que de le bloquer (opt-in par défaut).

Ceux qui veulent empêcher ce fonctionnement peuvent, avec Chrome, installer cette extension (https://chrome.google.com/webstore/detail/webrtc-block/nphkkbaidamjmhfanlpblblcadhfbkdm) pour bloquer.
Installer une extension pour combler une faille n'est PAS une solution acceptable.

(Je cherche une solution en modifiant le binaire à la main, comme pour virer le support HSTS.)

Dans Firefox ca se fait directement dans les flags (about:config) avec en désactivant "media.peerconnection.enabled".
C'est déjà moins pire.

Le débat si c'est une faille de sécurité ou juste un probleme de privacy/entreprise n'est bien sur pas tranché
Si beaucoup de gens pensent que c'est une faille alors c'est une faille.

et ne le sera peut-être jamais mais ce débat n'a rien à  faire dans le bugtracker de Chrome et n'a pas a le polluer (ca n'est pas non plus aux devs de Chrome de trancher la question mais plus a l'IETF et/ou ceux qui mettent au point les specs de WebRTC).
Non! Le débat est tout à fait à sa place dans le bugtracker. C'est fait pour ça un bugtracker. Dire que la norme est la merde est à sa place dans un bugtracker. C'est comme ça.

C'est un peu le même débat qu'avec le "user-agent" qui communique l'OS, sa version, le nom du navigateur, sa version a tout les sites qu'on consulte. Personne ne parle de faille de sécurité la ... sauf les extrémistes parano ;) Et avec IPv6 la question ne se pose même plus (sauf cas tordus).
Je vois pas le rapport avec IPv6.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Marin le 03 février 2015 à 17:19:57
Ce qui est drôle, c'est que WebRTC est tellement une usine à gaz, qu'il a fallu attendre plusieurs années après le début du développement et de l'implèmentation de cette technologie dans les principaux navigateurs, pour qu'un journaliste se rende finalement compte d'un de ses aspects de fonctionnement les plus basiques. Pour un développeur qui cherche à jouer ne serait-ce qu'un peu avec cette technologie, il est très difficile de passer à côté du fait que l'adresse IP locale est transmise dans les données SDP, vu que le développeur doit manipuler directement la variable qui contient ces informations pour la faire transiter via son serveur (la signaling channel).

Sinon, concernant les implications de sécurité de pouvoir connaître l'adresse IP locale du client web, cela doit être évalué sous au moins trois angles :
Dans tous les cas, se limiter à "débattre" des heures sur « non c'est une fonctionnalité », « si c'est une vulnérabilité » est stérile et manichéen, il s'agit comme beaucoup de choses une implication technique complexe qui peut être vue sur beaucoup d'angles. Je pense qu'essayer d'être un peu plus précis et factuels dans nos propos et dans notre façon de s'exprimer serait une bonne chose pour tout le monde...
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 18:10:26
Pas DU TOUT d'accord.

"il existe déjà dans les faits un bon nombre de manières d'envoyer du trafic vers le réseau local de l'utilisateur" mais pas de contourner le proxy SOCKS : j'ai un proxy SOCKS mais Chrome a décidé de parler UDP en contournant la config de proxy, c'est une violation de sécurité. Le proxy n'est pas là pour faire joli, ce n'est proxy SOCKS sauf pour UDP, c'est proxy SOCKS point.

- Je peux examiner les cookies, la présence d'autres données stockées dans le navigateur; et d'effacer ces données.

- Le mode navigation privée marche. Effacer les données de navigation marche. Tout cela doit suffit (merci de préciser si ce n'est pas le cas) pour "les trois tonnes de façons de tracer un utilisateur avec du JavaScript", "la manipulation du cache navigateur", etc.

Et si ça ne suffit pas, il y a la solution de changer de profil ou de compte utilisateur ou de navigateur!

- Java est en voie de disparition. Il est utilisé par très peu de sites et certainement pas un moyen discret pour la surveillance à grande échelle.

- "le test de nombreuses fonctionnalités spécifiques au navigateur" permet de distinguer les versions de navigateurs (c'est pour ça que le User-Agent HTTP n'est pas vraiment LE problème) pas les utilisateurs; ou les plugins installés, ou les fonts disponibles, ou les caractéristiques de ces fonts (taille). C'est inévitable vu qu'on peut mesurer le rendu d'une page HTML et les positions des retours à la ligne. Mais on peut avoir de nombreuses configs identiques.

Et si ça ne suffit pas, il y a la solution de navigateur pour changer de signature!

"cependant je n'ai encore vu passer d'article qui documente avec précision quels systèmes d'anonymisation, configurés à quel niveau du réseau, avec quels navigateurs et dans quels cas de figure peuvent poser problème dans le cadre de l'échange d'informations ICE."

Allo la Terre?

N'importe quel système NAT ou proxy HTTP ou proxy SOCKS qui cache l'adresse IP de l'utilisateur est neutralisé. En particulier les VPN "hide my ass".

"en tenant compte de l'existant, un vrai risque supplèmentaire" revient à dire qu'on passe d'une situation problématique à une situation encore plus merdique!

L'idée est qu'on se retrouve avec une merde qui casse complètement une propriété de sécurité.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: jack le 03 février 2015 à 21:03:15
Citer
Your network IP is:
10.0.0.13

Make the locals proud.

Et maintenant, il se passe quoi ?
Quel est le risque ?
Que peut-on faire avec cette donnée unique et donc précieuse ?

Tu as fait mieux dans le passé, tu peux te reprendre
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 21:06:36
Je peux noter cette information pour diminuer ton anonymat.

Fondamentalement la question est sans pertinence. Ce qu'il peut se produire par la suite n'est pas le sujet. Il s'est passé une chose : une information qui n'avait JAMAIS été facilement accessible, et qui n'avait PAS été révélée, est révélée. Point.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: jack le 03 février 2015 à 21:11:17
Bof, c'est une information qui, néanmoins, était connue à la conception : le nat n'est qu'une rustine, et cacher l'IP "locale" n'est qu'un effet de bord
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 03 février 2015 à 21:19:29
A la conception de quoi?

Cacher l'IP locale est l'effet principal recherché dans certains cas. Dans d'autres c'est un effet secondaire.

Dans certains cas l'effet recherché est d'empêcher absolument les connexions vers les machines à l'intérieur. Dans d'autres cas ce n'est pas voulu et on met des outils pour faciliter les connexions vers ces machines comme UPnP.

Il y a différents NAT : source NAT, dest NAT, redirect, proxy, Tproxy...

On peut utiliser le NAT pour faire une proxy HTTP transparent par exemple. Rustine, pas rustine?

Franchement, je ne sais pas ce qu'est une "rustine".
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: jack le 03 février 2015 à 23:20:26
À la conception d'IP.

Cacher l'IP locale est l'effet principal recherché dans certains cas. Dans d'autres c'est un effet secondaire.
Vraiment ?

Citation de: corrector
Dans certains cas l'effet recherché est d'empêcher absolument les connexions vers les machines à l'intérieur. Dans d'autres cas ce n'est pas voulu et on met des outils pour faciliter les connexions vers ces machines comme UPnP.
Chez les gens compétents, on utilise un parefeu pour ce faire.

Franchement, je ne sais pas ce qu'est une "rustine" : si tu penses pouvoir me faire gober que tu considères la majorité des utilisations du NAT comme étant légitime et fait "comme il se doit, pour une bonne raison", tu surestimes tes capacités :)
Nous savons tout les deux que la majorité du NAT est nefaste, et également que le NAT est utile dans certains cas.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Marin le 04 février 2015 à 06:57:19
"en tenant compte de l'existant, un vrai risque supplèmentaire" revient à dire qu'on passe d'une situation problématique à une situation encore plus merdique!

Non, ce que je veux dire, c'est que les systèmes de traçage avancés se basent sur un ensemble de propriétés pour établir une empreinte de l'utilisateur ; mais qu'en l'occurrence, l'entropie apportée par l'adresse IP locale n'est pas significative par rapport à la masse de données déjà utilisable dans la pratique. Que ça n'apporte pas de plus-value réelle pour la conception de ce genre de mécanisme, en somme.

Aujourd'hui, le comportement typique d'une box est d'offrir aux clients de son NAT une adresse quelque part dans 192.168.1.0/24... En définitive, on se retrouve avec une entrée qui admet, pour le très gros de la masse d'utilisateurs, à peine quelques centaines de valeurs possibles (bon, les utilisateurs d'entreprise pourront bien avoir quelque chose de plus original en 10.x.x.x, mais cela reste marginal à partir du moment où l'on considère un mécanisme de traçage d'une certaine échelle...), et qui n'est même pas stable ! Donc quand il est question de comparer avec :

- "le test de nombreuses fonctionnalités spécifiques au navigateur" permet de distinguer les versions de navigateurs (c'est pour ça que le User-Agent HTTP n'est pas vraiment LE problème) pas les utilisateurs; ou les plugins installés, ou les fonts disponibles, ou les caractéristiques de ces fonts (taille). C'est inévitable vu qu'on peut mesurer le rendu d'une page HTML et les positions des retours à la ligne. Mais on peut avoir de nombreuses configs identiques.

Déjà, il n'est pas non plus question de distinguer l'utilisateur ici, mais juste une de ses machines, et juste tant qu'elle restera connectée à ce routeur, et juste tant que les aléas de l'attribution DHCP voudront bien lui laisser son adresse... Ensuite, le nombre de configurations possibles en est ici d'autant plus réduit par la plage sur laquelle les routeurs grand public font leurs allocations d'adresses. Au final, je ne suis pas convaincu qu'on dispose d'un outil plus puissant que le canvas fingerprinting (qui ne relève pas du seul navigateur, mais davantage d'une combinaison navigateur+OS+GPU) en matière d'identification...

- Le mode navigation privée marche. Effacer les données de navigation marche. Tout cela doit suffit (merci de préciser si ce n'est pas le cas) pour "les trois tonnes de façons de tracer un utilisateur avec du JavaScript", "la manipulation du cache navigateur", etc.

Ça peut suffire, ou pas... ça dépend surtout du navigateur. Il est vrai que les fonctionnalités de navigation privée se sont significativement améliorées dernièrement, face à des outils comme Evercookie (http://samy.pl/evercookie/).

mais pas de contourner le proxy SOCKS : j'ai un proxy SOCKS mais Chrome a décidé de parler UDP en contournant la config de proxy, c'est une violation de sécurité. Le proxy n'est pas là pour faire joli, ce n'est proxy SOCKS sauf pour UDP, c'est proxy SOCKS point.
[...]
N'importe quel système NAT ou proxy HTTP ou proxy SOCKS qui cache l'adresse IP de l'utilisateur est neutralisé. En particulier les VPN "hide my ass".

Si c'est bien l'adresse IP WAN qui est révélée dans le cadre de l'utilisation du proxy SOCKS, clairement, c'est un comportement indésirable, contre-intuitif et enclin à la vulnérabilité.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Electrocut le 04 février 2015 à 09:40:51
Je peux noter cette information pour diminuer ton anonymat.

Fondamentalement la question est sans HS. Ce qu'il peut se produire par la suite n'est pas le sujet. Il s'est passé une chose : une information qui n'avait JAMAIS été facilement accessible, et qui n'avait PAS été révélée, est révélée. Point.
Tu le dis toi même, cela tient davantage d'un problème de "confidentialité" que d'une "faille de sécurité" ;)
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 10:56:55
Qu'est-ce qu'une faille?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 04 février 2015 à 11:56:24
Une autre façon de voir les choses:

Le probleme dans cette histoire, c'est qu'on considère la présence de NAT comme la 'norme' car c'est utilisé très souvent, du moins en IPv4.

Donc on en arrive soit compliquer soit a relever une 'faille' sur un nouveau protocole ou un nouveau service parce qu'en présence de NAT son fonctionnement a des conséquences nouvelles...

Si on retourne le chose: on peut dire que c'est le NAT la source du probleme et pas le nouveau protocole ou service... cela donne une perspective tout différente a ce cas particulier.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 12:51:50
Le probleme dans cette histoire, c'est qu'on considère la présence de NAT comme la 'norme' car c'est utilisé très souvent, du moins en IPv4.
Qui ça, on?

Le NAT est la source de quel problème?
Titre: Utilité du NAT
Posté par: corrector le 04 février 2015 à 14:53:36
Chez les gens compétents, on utilise un parefeu pour ce faire.

Franchement, je ne sais pas ce qu'est une "rustine" : si tu penses pouvoir me faire gober que tu considères la majorité des utilisations du NAT comme étant légitime et fait "comme il se doit, pour une bonne raison", tu surestimes tes capacités :)
Nous savons tout les deux que la majorité du NAT est néfaste, et également que le NAT est utile dans certains cas.
Le source-NAT (SNAT) est dans quasiment tous les cas subis. Il a été activé sur la box parce qu'il n'y a aucun moyen d'avoir à prix modique autant d'adresses routables sur Internet que de PC en IPv4.

Je considère ça comme assez légitime vu qu'il n'y a aucun moyen de faire autrement en IPv4 sans modifier les couches IP de toutes les machines connectées.

Cette réduction du besoin d'adresses est l'effet primaire et les effets du NAT en dehors de cet effet primaire sont des effets secondaires.

Un des effets secondaires est le fait de bloquer par défaut toutes les "connexions(*) entrantes(#)" au niveau de la box, caractéristique assez souvent considérée comme très souhaitable. C'est un effet "pare-feu".

Cet effet pare-feu peut évidemment être obtenu juste avec les outils iptables sans recourir au NAT, en IPv4 comme en IPv6.

(*) c'est difficile à définir, mais en pratique telles que définies par conntrack dans netfilter (aka iptables) dans linux, ou assimilé sur les autres OS

(#) sauf les "connexions" RELATED au sens de conntrack, ce qui peut concerner plus ou moins de cas suivant les modules netfilter chargés; il faut donc connaitre l'ensemble de modules netfilter (voir nf_conntrack* ici http://lxr.cpsc.ucalgary.ca/lxr/linux+v3.8/net/netfilter/ ) pour comprendre le comportement d'un pare-feu.
Titre: Utilité du NAT
Posté par: corrector le 04 février 2015 à 18:15:51
Franchement, je ne sais pas ce qu'est une "rustine" : si tu penses pouvoir me faire gober que tu considères la majorité des utilisations du NAT comme étant légitime et fait "comme il se doit, pour une bonne raison", tu surestimes tes capacités :)
Si tu penses pouvoir me convaincre qu'il y a une alternative au NAT dans ses utilisations typiques, vas-y...
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 18:38:56
Bof, c'est une information qui, néanmoins, était connue à la conception : le nat n'est qu'une rustine, et cacher l'IP "locale" n'est qu'un effet de bord
Ce topic n'est pas à propos du NAT.

Ce topic est à propos de :
La faille est une "feature" : webkitRTCPeerConnection
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 18:44:54
essais de comprendre comment ils fonctionnent avant de les insulter?
Non.

Je préfère toujours réagir dans l'émotion de l'instant et sans réfléchir davantage, je n'attends JAMAIS le lendemain pour répondre.

deja tu cites un extrais , incomplet
FAUX

Le message est complet.

Ajouter un label particulier notifie les personnes en charge de ce domaine ce qui déclenchent leur interventions.
OSEF de leur procédure.

Suites aux différentes interventions dans le suivi du bug ils en sont arriver a décider que , pour le moment, ce n'est pas un probleme de sécurité
Tu vois, on est d'accord, donc "l'extrait" que j'ai cité est suffisant.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 19:05:22
Non, ce que je veux dire, c'est que les systèmes de traçage avancés se basent sur un ensemble de propriétés pour établir une empreinte de l'utilisateur ;
Certes.

mais qu'en l'occurrence, l'entropie apportée par l'adresse IP locale n'est pas significative par rapport à la masse de données déjà utilisable dans la pratique.
La masse de données utilisables dépend de l'utilisateur.

Que ça n'apporte pas de plus-value réelle pour la conception de ce genre de mécanisme, en somme.
Parce que le traçage est déjà quasi-parfait en pratique!

Aujourd'hui, le comportement typique d'une box est d'offrir aux clients de son NAT une adresse quelque part dans 192.168.1.0/24... En définitive, on se retrouve avec une entrée qui admet, pour le très gros de la masse d'utilisateurs, à peine quelques centaines de valeurs possibles
Pas du tout.

192.168.x.0/24 ça fait des centaines de valeurs possibles, 192.168.x.y ça fait presque 2**16 possibilités. C'est pas totalement négligeable.

De toute façon, mon but n'est pas du tout d'entrer dans de subtiles considérations d'entropie ici, hein. Ce n'est juste pas le sujet du topic - sujet que je connais vu que c'est MOI et juste MOI qui ait créé ce topic.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: pasbefri le 04 février 2015 à 19:54:17
  • En tant que mécanisme de contournement de proxy/VPN : c'est sûrement le point le plus fragile, cependant je n'ai encore vu passer d'article qui documente avec précision quels systèmes d'anonymisation, configurés à quel niveau du réseau, avec quels navigateurs et dans quels cas de figure peuvent poser problème dans le cadre de l'échange d'informations ICE. Et ça doit bien être ce qui manque pour pouvoir èmettre un jugement précis là-dessus...
Combiné avec des failles uPnP, de l'interface box ouverte à tout va l'intérieur, je ne suis pas sûr que ce soit si innocent que ça
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Damien le 04 février 2015 à 20:18:25
Un tuto pour expliquer le bouton "Editer" à Corrector ?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 21:13:01
Plait-il?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Damien le 04 février 2015 à 21:15:26
Tu enchaîne les posts pour accentuer le bruit que tu veux faire ou pas ?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 21:26:00
Aucun intérêt.

On peut revenir au sujet?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: BadMax le 04 février 2015 à 21:40:40
C'est quoi le jeu ? énerver corrector ?

Pfff top facile...
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 21:40:58
OK, je commence à voir pourquoi certains ont pensé que ce topic était à propos du NAT :

Google Chrome WebRTC IP Address Leakage

Vulnerability Details:
Chrome has a vulnerability whereby internal IP addresses of users can be leaked using Javascript alone without notifying the user.

Affected Versions:
Chrome Version: Version 31.0.1650.63 m + Version 32.0.1700.72 beta-m Stable + Version 34.0.1781.0 Canary
Operating System: Windows 7 Service Pack 1

Reproduction Case:
The following can be executed in the Chrome console to reproduce the test case. A self-contained HTML file has also been attached.
[...]
ICI ce trouve le problème qui est le sujet principal du topic.

La suite est à propos des commentaires des dév sur ce problème; c'est le second sujet du topic :

Ce commentaire sous le bug est hallucinant :

#7 juberti@chromium.org
We considered this, but in the end I don't think that introducing user action makes sense. It's not a permission that is well understood ("do you want this application to enumerate your network interfaces?")

With the move to IPv6, the notion of NATed addresses goes away, so any concerns here around exposing internal addresses to applications are only significant in the short term.

If the main concern is the enumeration of all interfaces, one option could be to only return the interface that has the default route. This might complicate wwan/wlan handover scenarios though.

'tain, un dév de Chromium n'a absolument AUCUNE idée de ce qu'est le Monde réel!
Ce n'est PAS MOI qui mentionne le NAT, c'est un dév.

Un dév dont j'explique que c'est un ahuri. Quand je dis ça, ça veut pas dire que j'approuve les propos de ce crétin.


Donc le sujet n'a JAMAIS été le NAT et je n'ai pas varié sur ce point.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 21:43:11
C'est quoi le jeu ? énerver corrector ?

Pfff top facile...
Facile puisque je suis FURIEUX au départ. C'est le sujet du topic!

Je voudrais pouvoir virer le dév précité.
Titre: webkitRTCPeerConnection + NAT
Posté par: corrector le 04 février 2015 à 21:54:23
Chrome et Firefox respectent les specs de la norme WebRTC et se doivent donc de (indiquer à la page l'IP locale et privée du PC et non pas juste l'IP publique du NAT-machin)
Trop drôle.

1) Le NAT est-il standardisé?
2) Comment un périphérique derrière un NAT peut-il avoir un comportement standardisé indépendamment du NAT-machin qui est devant lui?

Tu veux imposer un comportement standard sur un non-standard; ça n'a aucun sens.
Titre: Explication de texte
Posté par: corrector le 04 février 2015 à 21:57:43
Tu enchaîne les posts pour accentuer le bruit que tu veux faire ou pas ?
Pour les mal-comprenants :

Ces messages correspondent à des sujets différents.

Le topic commence par deux sujets différents, j'en rajoute un troisième sujet principal, et ensuite de nombreux autres sujets liés sont discutés (dont l'intérêt du NAT, dont le traçage des utilisateurs).
Titre: Faille ou pas?
Posté par: corrector le 04 février 2015 à 22:07:21
Le débat si c'est une faille de sécurité ou juste un probleme de privacy/entreprise n'est bien sur pas tranché et ne le sera peut-être jamais
Tu peux me dire ce qui te permet de discerner une faille de sécu d'un "problème de privacy"?

Au fait, c'est quoi un "problème de privacy"?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: BadMax le 04 février 2015 à 22:17:37
En tout cas, l'utilisation (contournement ?) du NAT est décrit dans plusieurs RFC :
[RFC4787]  Audet, F., Ed., and C. Jennings, "Network Address
              Translation (NAT) Behavioral Requirements for Unicast
              UDP", BCP 127, RFC 4787, January 2007.

[RFC5245]  Rosenberg, J., "Interactive Connectivity Establishment
              (ICE): A Protocol for Network Address Translator (NAT)
              Traversal for Offer/Answer Protocols", RFC 5245,
              April 2010.

[RFC5382]  Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P.
              Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
              RFC 5382, October 2008.

[RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

[RFC5766]  Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using
              Relays around NAT (TURN): Relay Extensions to Session
              Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.

Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: BadMax le 04 février 2015 à 22:21:52
Ah pardon, j'avais oublié celle-là : https://tools.ietf.org/html/rfc2663 (https://tools.ietf.org/html/rfc2663)

RFC2663: IP Network Address Translator (NAT) Terminology and Considerations
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 22:33:16
() Firefox respectent les specs de la norme WebRTC et se doivent donc de fonctionner comme cela. Ils ont donc décider , par défaut, d'autoriser ce comportement plutôt que de le bloquer (opt-in par défaut).
Non, au contraire, Firefox n'a pas "décidé" ça.

Les dév Firefox ont décidé que les fonctionnalités de communication A/V exigent une confirmation et que donc l'accès à l'API WebRTC et au protocole STUN était contrôlée ainsi.

Ils se sont plantés.

Pas de chance, hein...

Citation :

Firefox attempts to prevent internal IP address leakage via the SDP offer description by requiring streams to be added to a RTC peer connection before createOffer() can be called. This is usually done through calling getUserMedia(), which requires user authorisation. Firefox also prevents MediaStream constructors from being called directly. However, a RTC data channel bypasses this requirement by creating a stream without any user prompts, as no access to camera or microphone is requested.

Please see the attached fftest.html file for an example. It will write out the SDP description into the page, which contains all identified IP addresses for the endpoint so that a P2P connection can be established. The peer.localDescription object can also be inspected in the console.


Actual results:

Internal IP addresses can be leaked to the web page without any user notification.


Expected results:

The root question here is whether the browser should be able to initiate and establish P2P connections without notifying the user. Based on other WebRTC behaviour implemented in Firefox, it appears that this was to be prevented so that internal IP addresses cannot be leaked to a web page without calling getUserMedia() and causing a user prompt. In any case, the WebRTC implementation should be made consistent with whatever is decided.

Source : https://bugzilla.mozilla.org/show_bug.cgi?id=959893
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 04 février 2015 à 22:45:54
Franchement, je ne sais pas ce qu'est une "rustine" : si tu penses pouvoir me faire gober que tu considères la majorité des utilisations du NAT comme étant légitime et fait "comme il se doit, pour une bonne raison", tu surestimes tes capacités :)
Nous savons tout les deux que la majorité du NAT est nefaste, et également que le NAT est utile dans certains cas.
Cette faille du navigateur crée justement une utilité pour le NAT : cette "fonctionnalité" expose l'adresse IP telle que vue par le navigateur; il faut donc cacher au navigateur l'adresse IP.

Pour faire cela, le plus simple est de mettre le navigateur sur une machine en IP privée et éventuellement d'utiliser le NAT pour la connectivité.

Les tentatives du navigateur de découvrir l'adresse IP publique via UDP seront aisèment bloquées avec un pare-feu.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 05 février 2015 à 15:28:33
Ce qui est drôle, c'est que WebRTC est tellement une usine à gaz, qu'il a fallu attendre plusieurs années après le début du développement et de l'implèmentation de cette technologie dans les principaux navigateurs, pour qu'un journaliste se rende finalement compte d'un de ses aspects de fonctionnement les plus basiques. Pour un développeur qui cherche à jouer ne serait-ce qu'un peu avec cette technologie, il est très difficile de passer à côté du fait que l'adresse IP locale est transmise dans les données SDP, vu que le développeur doit manipuler directement la variable qui contient ces informations pour la faire transiter via son serveur (la signaling channel).
Exact.

XMLHttpRequest,
oui mais uniquement vers la même "origine" (donc pas de CSRF possible).

les WebSockets, voire même les frames et les formulaires HTML basiques,
Oui : formulaire + JS = GET/POST vers n'importe quel domaine et CSRF possible (sauf à utiliser un plugin comme NoScript qui anonymise ("sandbox") certaines requêtes).

il existe déjà dans les faits un bon nombre de manières d'envoyer du trafic vers le réseau local de l'utilisateur, d'en obtenir quelques informations en retour (via la gestion d'erreurs), peut-être même d'identifier l'adresse IP locale de l'utilisateur d'une de ces autres manières,
Oui cette page utilise d'abord WebRTC et ensuite des liens HTTPS pour découvrir les machines locales :

https://dl.dropboxusercontent.com/u/1878671/enumhosts.html

sans pour autant qu'il n'y ait la possibilité d'envoyer des paquets qui soient complètement arbitraires au niveau TCP/UDP.
Oui, le navigateur est potentiellement un véritable espion.

L'exploitation d'une faille CSRF ou XSS vers l'interface administration du routeur de l'utilisateur, via l'adresse locale de celle-ci, depuis une page web totalement quelconque, est quelque chose de déjà fait et déjà vu (je peux dire qu'il y a déjà eu des vulnérabilités connues de ce type pour au moins les box de tous les principaux FAI français).
Sur Freebox pre-ution, il n'y pas d'interface d'admin locale, donc zéro surface d'attaque!

Sur l'interface de gestion en free.fr, l'authentification n'est pas ambiante (la session est dans l'URL) donc aucun CSRF possible.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 05 février 2015 à 16:08:50
Ca n'est pas WebRTC lui-même qui est une usine a gaz mais plutot tout les mécanismes utilisés autour pour le faire fonctionner dans le 'monde réel' ou le NAT est omni-présent.
Une tres bonne intro a ce sujet: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP et avec des restrictions assez fortes (port ouvert, adresse partagée, etc). On est tellement confronter a cela que pour beaucoup de gens ca devient la 'norme' et l'IP 'normale' du début d'Internet devient l'exception...un comble !

Franchement et je rejoint le dev de Chrome qui parlais de ca: vivement qu'IPv6 prenne la relève qu'on se débarrasse de cet ersatz d'IP actuel qui complique toute innovation, promeut un modèle centralisé et donne un faux sentiment de sécurité (au point que des gens s'affolent qu'on communique leur IP locale sans leur dire).

Si ce 'bug/faille/whatever' de WebRTC peut être une pierre de plus pour promouvoir IPv6, j’espère qu'ils ne le corrigeront jamais ;D

Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 05 février 2015 à 17:39:36
N'importe quoi, encore.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Snickerss le 05 février 2015 à 18:41:04
Corrector me fatigue mais je reconnais qu'il arrive à provoquer des réponses intéressantes donc merci quand même au final ;)
Titre: Client léger vs. client lourd
Posté par: corrector le 05 février 2015 à 19:56:20
Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P
N'importe quoi, une fois de plus.

On ne se protège pas de la NSA avec des sites en WebRTC, il faut un client lourd - qui peut être du JS exécuté dans un navigateur avec l'API WebRTC, évidemment.
Titre: Client léger vs. client lourd
Posté par: kgersen le 05 février 2015 à 20:49:28
Au bout d'un moment c'est lassant cette lourdeur. Je remet mon filtre.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Breizh 29 le 05 février 2015 à 21:10:48
Qui a piqué les "louzoù" de corrector  :o
Qu'on les lui rende immédiatement.  ;D
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 05 février 2015 à 21:36:35
Ca n'est pas WebRTC lui-même qui est une usine a gaz mais plutot tout les mécanismes utilisés autour pour le faire fonctionner dans le 'monde réel' ou le NAT est omni-présent.
Une tres bonne intro a ce sujet: http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/

On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP et avec des restrictions assez fortes (port ouvert, adresse partagée, etc). On est tellement confronter a cela que pour beaucoup de gens ca devient la 'norme' et l'IP 'normale' du début d'Internet devient l'exception...un comble !

Franchement et je rejoint le dev de Chrome qui parlais de ca: vivement qu'IPv6 prenne la relève qu'on se débarrasse de cet ersatz d'IP actuel qui complique toute innovation, promeut un modèle centralisé et donne un faux sentiment de sécurité (au point que des gens s'affolent qu'on communique leur IP locale sans leur dire).

Si ce 'bug/faille/whatever' de WebRTC peut être une pierre de plus pour promouvoir IPv6, j’espère qu'ils ne le corrigeront jamais ;D
Comme je viens de le dire, cette faille de sécurité est une raison de mettre en place le NAT, et non un argument contre le NAT : tu veux utiliser un navigateur sans dévoiler la vraie IP du PC qui exécute le navigateur? Alors tu mets une IP privée sur une machine virtuelle et du NAT sur la vraie IP du PC.

Donc WebRTC est une pierre pour promouvoir le NAT en IPv6 - qui est tout aussi utile qu'en IPv4.

Et tu oublies qu'un navigateur Web n'est qu'un client jusqu'à présent, et qu'avant d'en faire un serveur il faudrait demander l'avis de l'utilisateur.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: jack le 05 février 2015 à 21:53:16
Non.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 05 février 2015 à 22:41:23
Non quoi?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 05 février 2015 à 22:49:03
En tant que vecteur d'attaques réseau : je ne pense pas qu'il y ait grand chose à voir de ce côté là. Entre Image.src, XMLHttpRequest, les WebSockets, voire même les frames et les formulaires HTML basiques, il existe déjà dans les faits un bon nombre de manières d'envoyer du trafic vers le réseau local de l'utilisateur, d'en obtenir quelques informations en retour (via la gestion d'erreurs), peut-être même d'identifier l'adresse IP locale de l'utilisateur d'une de ces autres manières, sans pour autant qu'il n'y ait la possibilité d'envoyer des paquets qui soient complètement arbitraires au niveau TCP/UDP.
Découverte des machines locales avec juste l'élèment IMG :

function probeIp(ip, timeout, cb) {
  var start = Date.now();
  var done = false;
  var img = document.createElement('img');
  var clean = function() {
    if (!img) return;
    document.body.removeChild(img);
    img = null;
  };
  var onResult = function(success) {
    if (done) return;
    done = true;
    clean();
    cb(ip, Date.now() - start < timeout);
  };
  document.body.appendChild(img);
  img.style.display = 'none';
  img.onload = function() { onResult(true); };
  img.onerror = function() { onResult(false); };
  img.src = 'https://' + ip + ':' + ~~(1024+1024*Math.random()) + '/I_DO_NOT_EXIST?' + Math.random();
  setTimeout(function() { if (img) img.src = ''; }, timeout + 500);
}

function probeNet(net, onHostFound, onDone) {
  net = net.replace(/(\d+\.\d+\.\d+)\.\d+/, '$1.');
  var timeout = 5000;
  var done = false;
  var found = [];
  var q = new TaskController(5, onDone);
  for (var i = 1; i < 256; ++i) {
    q.queue((function(i, cb) {
      probeIp(net + i, timeout, function(ip, success) {
        if (success) onHostFound(ip);
        cb();
      });
    }).bind(this, i));
  }
}

https://dl.dropboxusercontent.com/u/1878671/enumhosts.html

Ouvrir la console et regarder les requêtes réseau.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 05 février 2015 à 23:53:03
tu veux utiliser un navigateur sans dévoiler la vraie IP du PC qui exécute le navigateur?

Je crois que toute ta confusion elle la depuis le début de ce topic et qu'on parle pas des mêmes choses.

A partir du moment ou j’accède a Internet je ne veux pas cacher mon IP. Que ce soit celle de ma box ou de mon PC, personnellement je m'en tape ainsi que 99% des utilisateurs d'ailleurs.

Si je veux utiliser un navigateur sans dévoiler la vraie IP du PC (ou de la box) c'est autre chose. On parle d'anonymisation la, mise en oeuvre   en utilisant un VPN ou autre. C'est différent. Si cette 'faille' de WebRTC casse certains systèmes d'anonymisation alors effectivement c'est un souci mais  qui est le fautif ? le système d'anonymisation ou WebRTC (enfin plutot TURN/STUN/ICE d'ailleurs) ? Marin avait déja très bien résumé la chose dans son 1er post: il faut en savoir plus pour trancher.

En IPv6 on n'a pas ce probleme, on n'utilise pas TURN/STUN/ICE et si on passe par un VPN celui ci fournit aussi une IP unique (donc pas de NAT) donc on n'a pas non plus besoin de TURN/STUN/ICE.

Et un gars de www.webrtc.org vient encore d'éclairer la chose dans le suivi du bug (https://code.google.com/p/chromium/issues/detail?id=333752#c39) sur le tracker:
Citer
The current concerns regarding this issue are mostly focused around sites detecting the ISP public IP address in VPN situations, which I think is a different problem from what is being discussed here (i.e. the private address is not the concern).

J'ai testé rapidement avec 2 systèmes de VPN (locaux au PC) avec https://diafygi.github.io/webrtc-ips/ :
Avec un simple PPTP, ca n'affiche que mon IP public en sortie du VPN donc c'est ok
Avec TunnelBear (VPN pour Mr Tout le monde), ca m'affiche les 2 IP publics, la sortie du VPN et mon IP public SFR. Donc la il y a un souci mais a qui la faute ? M'enfin bon c'est TunnelBear quoi...


Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 13:52:13
Je crois que toute ta confusion elle la depuis le début de ce topic et qu'on parle pas des mêmes choses.
Pourtant ça me semble facile à comprendre :
1) WebRTC est arrivé par une MàJ; personne n'a été prévenu
2) WebRTC est activé par défaut
3) c'est une API donne accès aux IP locales - sans confirmation de l'utilisateur qui est trop con pour comprendre ce qu'on lui demande (https://code.google.com/p/chromium/issues/detail?id=333752#c39)
4) un site peut demander au navigateur d'utiliser UDP pour découvrir son adresse IP publique, en ignorant les proxy HTTP et SOCKS configurés - sans confirmation de l'utilisateur
5) le monde entier considère que c'est une faille sérieuse
6) seuls les dévs Chrome se bouchent les oreilles

A partir du moment ou j’accède a Internet je ne veux pas cacher mon IP.
Et ça te dérange pas d'avoir cet identifiant stable qui permet de recouper les logs?

Moi si!

Et non, je ne pense pas qu'une IP dynamique (changeant chaque semaine) soit la solution.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 07 février 2015 à 16:17:12
Pourtant ça me semble facile à comprendre :
1) WebRTC est arrivé par une MàJ; personne n'a été prévenu
Ceux qui ont besoin d'être prévenu l'ont été ou étaient au courant de toute facon, les autres (le gros des utilisateurs) n'ont effectivement pas besoin d'être explicitement prévenu. De toute façon comment veux tu 'prevenir' ? sous qu'elle forme ? et ca rejoint le point 3

2) WebRTC est activé par défaut
oui et alors? cela a permit un basculement P2P (quand c'est possible) de Hangouts notamment donc un gros soulagement d'un trafic autrefois centralisé. Cela permet aussi de nouveau services comme du partage de fichier P2P sans avoir a installer de plugins (exemple: https://www.sharefest.me/ ). Ca convient a 99,9% des utilisateurs. C'est la philosophie des navigateurs modernes d'évoluer constamment en activant parfois de nouveaux protocoles ou fonctions. Si t'es dans le 0,1% : pas de bol pour toi.

3) c'est une API donne accès aux IP locales - sans confirmation de l'utilisateur qui est trop con pour comprendre ce qu'on lui demande (https://code.google.com/p/chromium/issues/detail?id=333752#c39)

'con' n'est pas le mot, au contraire. Effectivement 99% des utilisateurs ne sauraient pas quoi répondre. Il ne s'agit de pas les prendre pour des cons mais plutot de leur fournir de la simplicité, c'est ce qu'ils demandent depuis longtemps envers l'informatique: ils en ont marre de voir des messages abscons ou de devoir faire des réglages bizarres. A partir du moment ou il font confiance a un éditeur en utilisant son logiciel ils demandent cette simplicité. A charge a l'éditeur de garder leur confiance : le deal est la, on n'est plus dans les années 90.

4) un site peut demander au navigateur d'utiliser UDP pour découvrir son adresse IP publique, en ignorant les proxy HTTP et SOCKS configurés - sans confirmation de l'utilisateur
C'est pour ca que le bug est classé 'privacy/entreprise': proxy HTTP et SOCKS c'est du monde de l'entreprise. Il y a un service informatique en charge de verrouiller tout ca (en général on bloque udp de toute facon quand on a un proxy HTTP ou SOCKS). Si tu as une configuration bâtarde mi-grand public/mi-entreprise tu sors du cadre nominal : les devs ne peuvent prevoir tout les cas de toute facon. cf 0,1% du point 2.

5) le monde entier considère que c'est une faille sérieuse
archi faux. qui?  Le 'bug' est ouvert depuis plus d'un an et personne n'a bronché. La communauté sécurité est courant depuis bien avant (webrtc a commencé sur Firefox avant d'être sur Chrome).
Ton "monde entier" = la bande de bobo geeks qui pensent avoir un peu compris l'informatique et sa sécurité et se croient autorisés a définir ce qui est 'bien' ou "sérieux" ou "une faille". C'est le 0,1% encore une fois. La plaie de l'informatique moderne. Les mecs qu'on jamais pondu une ligne de code et qui donnent des leçons de programmation a la planète, des gens incapables de se mettre a la place de l'utilisateur lambda et de lui faciliter la vie. Si on est les écoutait on serait encore a l'age des pigeons voyageurs parce que leur débats et discussions sur quoi faire ne terminent jamais.

Et ça te dérange pas d'avoir cet identifiant stable qui permet de recouper les logs?

Moi si!

Et non, je ne pense pas qu'une IP dynamique façon (changeant chaque semaine) soit la solution.

non ca me dérange pas car Marin a bien expliqué les choses sur la 'signature' en général.
Et je ne suis pas parano et je ne crois pas au recoupement massifs des logs de toute façon. et surtout je m'en tape.

Tout produit que ce soit un navigateur Internet ou une voiture est conçu en fonction d'une cible d'utilisateurs et d'un certain usage. Si tu détourne l'usage ou sort des specs de fonctionnement c'est stérile de critiquer le produit ou ses créateurs: ils en ont rien a taper de toi et ce qui tu penses: t'es pas leur cible.

Il faut juste que tu te trouve un autre produit qui correspondra plus a tes besoins de sécurité et confidentialité, qui ne se met pas a jour tout seul et qui te demande confirmation a chaque fois qu'il fait quelque chose qu'il sait que tu n'as pas déjà fait et que tu veux savoir qu'il va faire... (bref une IA ?).
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 16:43:46
Ceux qui ont besoin d'être prévenu l'ont été ou étaient au courant de toute facon,
Délire complet, encore.

Le monde entier est en train de hurler à la faille.

Circulez, y a rien à voir! Tu dois bosser pour Apple et Microsoft! (C'est pas un compliment, hein. C'est même une insulte.)

les autres (le gros des utilisateurs) n'ont effectivement pas besoin d'être explicitement prévenu. De toute façon comment veux tu 'prevenir' ? sous qu'elle forme ? et ca rejoint le point 3
Par un message "cette màj change le comportement du navigateur (blablabla) pour revenir à l'ancien comportement cliquez ici"

Par une demande de permission par exemple.

Quand une extension demande l'accès à une API supplèmentaire, je suis prévenu!

oui et alors? cela a permit un basculement P2P (quand c'est possible) de Hangouts notamment donc un gros soulagement d'un trafic autrefois centralisé. Cela permet aussi de nouveau services comme du partage de fichier P2P sans avoir a installer de plugins (exemple: https://www.sharefest.me/ ). Ca convient a 99,9% des utilisateurs. C'est la philosophie des navigateurs modernes d'évoluer constamment en activant parfois de nouveaux protocoles ou fonctions. Si t'es dans le 0,1% : pas de bol pour toi.
Super. Vive le P2P.

A charge a l'éditeur de garder leur confiance :
Voilà, Chrome jette ses utilisateurs sous le bus, super.

C'est pour ca que le bug est classé 'privacy/entreprise': proxy HTTP et SOCKS c'est du monde de l'entreprise. Il y a un service informatique en charge de verrouiller tout ca (en général on bloque udp de toute facon quand on a un proxy HTTP ou SOCKS). Si tu as une configuration bâtarde mi-grand public/mi-entreprise tu sors du cadre nominal : les devs ne peuvent prevoir tout les cas de toute facon. cf 0,1% du point 2.
C'est de la merde ce que tu dis.

Ton "monde entier" = la bande de bobo geeks
tout ceux qui n'ont pas de la merde dans le crane.

Et je ne suis pas parano et je ne crois pas au recoupement massifs des logs de toute façon. et surtout je m'en tape.
Tout le monde s'en tape que tu t'en tapes.

Tout produit que ce soit un navigateur Internet ou une voiture est conçu en fonction d'une cible d'utilisateurs et d'un certain usage. Si tu détourne l'usage ou sort des specs de fonctionnement c'est stérile de critiquer le produit ou ses créateurs: ils en ont rien a taper de toi et ce qui tu penses: t'es pas leur cible.
C'est de la merde ce que tu dis.

Merci de cesser de polluer ce topic.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 16:48:32
essais de comprendre comment ils fonctionnent avant de les insulter?

deja tu cites un extrais , incomplet et hors contexte.
Tu as été incapable de citer ce fumeux contexte, ni le reste du message, ce que prouve que tu n'es qu'un TROLL.

Tant que tu n'es pas capable de citer ce contexte pertinent, tu es BANNIS de ce topic.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 16:58:25
On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP et avec des restrictions assez fortes (port ouvert, adresse partagée, etc). On est tellement confronter a cela que pour beaucoup de gens ca devient la 'norme' et l'IP 'normale' du début d'Internet devient l'exception...un comble !
Exact

Franchement et je rejoint le dev de Chrome qui parlais de ca: vivement qu'IPv6 prenne la relève qu'on se débarrasse de cet ersatz d'IP actuel qui complique toute innovation,
Dans ton délire tu as réussi à ne pas voir que c'est ce que je dis depuis des années.

(le NAT généralisé) promeut un modèle centralisé
Sauf que UPnP IGD est généralisé, donc il y a au contraire une envie de connectivité entre box et les moyens de la mettre en place.

et donne un faux sentiment de sécurité
Pas plus qu'un pare-feu. C'est un pare-feu.

(au point que des gens s'affolent qu'on communique leur IP locale sans leur dire).
trololol

Si ce 'bug/faille/whatever' de WebRTC peut être une pierre de plus pour promouvoir IPv6, j’espère qu'ils ne le corrigeront jamais ;D
C'est le bordel dans ta tête.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 17:03:21
En tant que mécanisme de traçage persistent : honnêtement, entre les trois tonnes de façons de tracer un utilisateur avec du JavaScript (sessionStorage/localStorage/globalStorage/document.cookie..., le rendu <canvas>...), un plugin quelconque (Flash : les LSO, les divers moyens de communication réseau souvent peu maîtrisés..., également toutes les CVE et fonctionnalités peu maîtrisées de Java, Silverlight...), les en-têtes HTTP (les cookies, l'User-Agent, l'E-Tag...), la manipulation du cache navigateur, le test de nombreuses fonctionnalités spécifiques au navigateur (niveau JS, CSS...)... je ne pense pas que savoir que l'utilisateur est identifié comme 192.168.1.54 derrière le NAT de sa box représente, en tenant compte de l'existant, un vrai risque supplèmentaire en matière de traçage pour l'utilisateur lambda, et l'utilisateur avancé ayant un intérêt pour la protection de sa vie privée aura de toutes manières toujours un moyen de de passer outre.
qui est?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 17:05:52
Bof, c'est une information qui, néanmoins, était connue à la conception : le nat n'est qu'une rustine, et cacher l'IP "locale" n'est qu'un effet de bord
Il me semble que c'était au contraire un des effets recherchés.

Enfin, effet initialement principale ou secondaire ça n'a aucune importance; pour l'utilisateur final, l'effet principal peut être l'effet secondaire pour le concepteur.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 17:08:20
Tu le dis toi même, cela tient davantage d'un problème de "confidentialité" que d'une "faille de sécurité" ;)
La confidentialité est une propriété de sécurité.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 07 février 2015 à 17:36:16
Le monde entier est en train de hurler à la faille.

C'est sur il y a eu un reportage sur TF1 d'ailleurs et Hollande et Merkel ont mis au point un plan qu'ils vont présenté a Larry la semaine prochaine...

T'as définition du 'monde entier' est curieuse. On doit pas vivre dans le même monde.
Même les gros médias/blogs geeks habitués du clickbait n'ont pas relevé l'info, y'a guerre que les sites 'fumeux' qui traitent de torrents et autres trucs du genre qui en on parler et pour cause...

T'as des liens un peu sérieux qui 'hurlent a la faille' ?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 17:53:00
Quels blogs n'ont pas signalé cette faille?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 18:24:31
Je ne crois pas avoir posté ce lien :

https://www.browserleaks.com/webrtc
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Snickerss le 07 février 2015 à 19:09:21
"Le monde entier hurle au danger du nucléaire"
==> corrector demande des sources (ou le monde entier est con, ça dépend des humeurs)

"Le monde entier hurle à la faille"
==> bon on le croit sur parole  ;D
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 19:28:07
Heu... tu mets sur le même plan les "dangers" du nucléaire et les dangers des navigateurs?

Les dangers du nucléaires sont imaginaires, c'est avéré par des dizaines d'études très solides et surtout par l'expérience pratique.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: Snickerss le 07 février 2015 à 19:31:50
Je mets au même plan le fait de citer "le monde" pour donner du poid à un argument qui n'en a pas forcèment.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: BadMax le 07 février 2015 à 19:34:36
Pas mal. 6 pages avant que le troll du nucléaire n'apparaisse.

Du coup ce topic étant en-dessous de la moyenne d'un troll/page, ne devrait-on pas le clore ?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 19:43:33
Citer
So something that screws users security and privacy was on by default in Firefox and Chrome.
What's an alternative browser to this crap?
https://www.reddit.com/r/technology/comments/2ttlcv/websites_can_detect_your_local_ips_and_make/co2mi0h

Pas mieux!
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 07 février 2015 à 21:05:02
Je mets au même plan le fait de citer "le monde" pour donner du poid à un argument qui n'en a pas forcèment.
Allo la Terre?

Je ne discute pas le fait que beaucoup de gens sont inquiets à propos du nucléaire. Je dis juste qu'on leur a menti continuellement.

Si Chrome n'a pas de faille, alors qu'est-ce qu'on appelle une faille?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: kgersen le 08 février 2015 à 11:51:17
Pas mal. 6 pages avant que le troll du nucléaire n'apparaisse.

Du coup ce topic étant en-dessous de la moyenne d'un troll/page, ne devrait-on pas le clore ?

Excellent ! Apres la loi de Godwin (https://fr.wikipedia.org/wiki/Loi_de_Godwin), je propose la 'loi de Corrector', loi identique mais avec le nucléaire au lieu du nazisme/Hitler.  ;D

Je définirai également le "wikitorisme", manœuvre qui, des qu'on a cours d'arguments sur un sujet, consiste a botter en touche en demandant la définition des mots-clé  du sujet évoqué.

exemples:
Qu'est-ce qu'on appelle une faille ?
Que signifie 'privacy' ou confidentialité ?
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: vivien le 09 février 2015 à 13:11:25
Maintenant, c'est moi qui bloque le sujet définitivement, après les propos vulgaires de Corrector ("Petite bite" "Suicide toi connard" ...)
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 06 mai 2015 à 04:04:33
Plusieurs releases plus tard, la faille de sécurité est toujours présente, les dévs se foutent ouvertement du monde, rien n'est prévu.

Moi j'ai une solution fiable : supprimer toutes les occurrences de RTC dans les fichiers binaires. Méchant mais efficace.
Titre: Faille RTCPeerConnection, suite
Posté par: thenico le 06 mai 2015 à 12:43:03
Tu peut aussi compiler Firefox avec --disable-webrtc (ou utiliser le build fournis par le projet Tor).
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 06 mai 2015 à 12:51:30
Marche pas pour Google Chrome
Titre: Faille RTCPeerConnection, suite
Posté par: kgersen le 06 mai 2015 à 14:58:08
Depuis Chrome 42, la faille feature peut-être désactivée manuellement en éditant les préférences de Chrome:

1. aller sur chrome://version
2. noter le chemin d’accès au profil: "Profile Path" (sur windows, par défault c'est C:\Users\<login>\AppData\Local\Google\Chrome\User Data\Default)
3. quitter completement Chrome , y compris le processus en tache de fond (icone dans la barre des taches). Par sureté, verifier avec le gestionnaire de taches qu'aucun processus 'chrome' ne tourne (important car le fichier de config n'est lu qu'une fois au démarrage de Chrome).
4. Avec un éditeur de texte, ouvrir le fichier "Preferences" situé dans le répertoire du profile (repéré a l'étape 2). Par sûreté en faire une copie éventuellement.
5. ajouter dans ce fichier texte, a la fin, juste avant le dernier "}":
   ,
   "webrtc": {
      "multiple_routes_enabled": false
   }
(la virgule est à  mettre apres l'avant dernier } donc.
6. sauvegarder et relancer Chrome
7. lancer/connecter votre VPN s'il n'est pas déja en service
8. aller sur http://ipleak.net pour vérifier que vos IP ne sont plus visibles

oui c'est plus "compliqué" qu'un simple flag a changer par exemple mais c'est a dessein.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 06 mai 2015 à 16:27:44
C'est exprès que les utilisateurs sont vulnérables.

Noté Google, tu n'hésites pas à balancer les utilisateurs sous le bus.
Titre: Faille RTCPeerConnection, suite
Posté par: kgersen le 06 mai 2015 à 16:36:57
C'est exprès que les utilisateurs sont vulnérables.

Noté Google, tu n'hésites pas à balancer les utilisateurs sous le bus.

quels utilisateurs sont vulnérables?

Uniquement ceux qui utilisent des mauvaises solutions de VPN ...(ou configuration de celui ci)

C'est pas que la faute de Chrome si l'IP public du VPN fuit ... avec un bon systeme VPN ca ne fuit pas.

Donc c'est a Chrome/WebRTC de corriger les défaillances d'une solution du niveau d'en dessous (couche réseau) ?

Les "amateurs" ont ce qu'ils méritent.


Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 06 mai 2015 à 16:45:32
Tous sont qui font confiance à Google pour le pas les balancer sous le bus.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 01:18:20
Donc c'est a Chrome/WebRTC de corriger les défaillances d'une solution du niveau d'en dessous (couche réseau) ?
Tu considères un certain comportement comme normal.

Nous considérons ce comportement comme anormal.

Je pense que nous sommes la majorité. La majorité a raison.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 01:29:42
[Continuation d'une discussion d'un topic bloqué]

https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/

Citation de: Marin
Entre Image.src, XMLHttpRequest, les WebSockets, voire même les frames et les formulaires HTML basiques, il existe déjà dans les faits un bon nombre de manières d'envoyer du trafic vers le réseau local de l'utilisateur

Ben oui; mais si cela existe depuis Netscape 3, alors les utilisateurs sont censés savoir que ça existe.

Avec IMG tu fais tous les HTTP GET que tu veux, avec FORM tu fais tous les HTTP POST que tu veux, avec du JS tu en fais 13 à la douzaine.

Je considérerais AUSSI cela comme une faille si ces fonctions débarquaient tout d'un coup dans une MàJ d'un logiciel qui ne permettait RIEN de cela!!!!

Mais tout le monde doit savoir qu'un navigateur est un petit logiciel espion qui fait des connexions TCP vers n'importe quelle IP plus ou moins privée de votre réseau.

Citer
honnêtement, entre les trois tonnes de façons de tracer un utilisateur avec du JavaScript (sessionStorage/localStorage/globalStorage/document.cookie..., le rendu <canvas>...), un plugin quelconque (Flash : les LSO, les divers moyens de communication réseau souvent peu maîtrisés..., également toutes les CVE et fonctionnalités peu maîtrisées de Java, Silverlight...), les en-têtes HTTP (les cookies, l'User-Agent, l'E-Tag...), la manipulation du cache navigateur
...sont des variations sur le principe du simple témoin HTTP.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 01:34:12
https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg198739/#msg198739

Citer
Your network IP is:
10.0.0.13

Make the locals proud.

Et maintenant, il se passe quoi ?
Quel est le risque ?
Que peut-on faire avec cette donnée unique et donc précieuse ?

Dans ce cas précis, pas grand chose. Mais j'espère que tu comprends que tu ne peux pas dire qu'une faille n'est pas une faille parce que dans un cas précis elle ne cause pas de souci.

Dans certains cas, j'ai deux adresses IP privées, sur deux sous-réseaux différents. Cette situation est beaucoup beaucoup plus rare donc pourrait servir à m'identifier.

Dans certains cas, le PC a une adresse routable sur Internet. C'est cette adresse routable sur Internet qui est révélée.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 01:51:29
[Continuation d'une discussion d'un topic bloqué]

https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg199021/#msg199021

Citation de: kgersen
Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P
NON, le Web n'est PAS "non centralisé", JAMAIS.

Le Web dépend du DNS. Le DNS est centré, centralisé, hiérarchisé... et décentralisé au sens de la décentralisation française, qui procède de l'Etat jacobin qui attribue des compétences de façon discrétionnaire.

Tout domaine peut être saisi par une autorité, volé par un pirate, tout site Web peut être "défacé", etc.

Il suffit souvent d'un outil comme "analytics" ou un "widget" sur une page pour que quiconque contrôle le domaine de cet élèment contrôle la page et puisse intercepter les communications, voler les identifiants, etc. Je pensais qu'un expert comme toi savait tout cela.

C'est pour ça qu'il faut des clients lourds, c'est à dire des logiciels installés sur des millions de machines, sans MàJ automatiques; ces clients lourds pourraient être des choses très légères, comme des plugin ou applications de navigateur (à condition que le navigateur ne soit pas trop dans le cloud...).
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 01:55:43
[Continuation d'une discussion d'un topic bloqué]

https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg199021/#msg199021

Citer
On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP ()
Pardon, la Freebox gère aussi SCTP. ;)
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 02:04:12
https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg199086/#msg199086

Citer
A partir du moment ou j’accède a Internet je ne veux pas cacher mon IP. Que ce soit celle de ma box ou de mon PC, personnellement je m'en tape ainsi que 99% des utilisateurs d'ailleurs.
C'est peut être le cas de 99,999 %, mais les 0,001 avaient un contrat en bonne et due forme : en indiquant l'utilisation d'un proxy HTTP ou TCP SOCKS, les connexions sortantes passaient toutes par ce proxy.

Mais là tout d'un coup, des paquets UDP ne passent pas par le proxy.

C'est une violation du contrat.

La violation du contrat est une faille de sécurité.

CAPISH?
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 02:31:55
https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg199476/#msg199476

Citation de: kgersen
T'as définition du 'monde entier' est curieuse. On doit pas vivre dans le même monde.
Même les gros médias/blogs geeks habitués du clickbait n'ont pas relevé l'info, y'a guerre que les sites 'fumeux' qui traitent de torrents et autres trucs du genre qui en on parler et pour cause...

T'as des liens un peu sérieux qui 'hurlent a la faille' ?

Je ne connais aucun site sérieux qui traite d'informatique, déjà. Tu as des liens sérieux, toi, sur quoi que ce soit?

Mais j'ai ça :

https://korben.info/proteger-faille-webrtc.html

Citer
Êtes vous bien planqué ou pas derrière votre proxy, votre VPN ou votre réseau Tor / Freenet / i2P ?

Difficile à dire surtout depuis que Daniel Roesler a découvert une faiblesse dans le protocole WebRTC qui permet grâce à un peu d'astuce et de JavaScript, de récupérer l'adresse IP locale et publique de l'internaute.

http://www.programmez.com/actualites/une-faille-de-webrtc-devoile-les-adresses-ip-que-vous-pensiez-masquer-en-utilisant-un-vpn-22106

Citer
Cette faille est décrite sur le blog de torguard.net, une société qui propose des services de VPN justement. Les VPN, pour Virtual Private NetVork sont souvent utilisés comme passerelle vers Internet, par ceux qui désirent masquer leur adresse IP et conserver un certain anonymat.

Dans ce cas, lorsqu'ils surfent, c'est l'adresse IP du proxy utilisé qui est visible sur Internet, non celle de leurs machines propres. Un serveur de site, par exemple, ne peut donc pas connaître l'IP réelle.

Ceci quand tout va bien... :-)

Seulement voilà, une faille dans le protocole WebRTC, implèmenté par les navigateurs Firefox et Chrome, permet de révéler l'IP réelle d'un internaute utilisant un VPN. Des requêtes émises via ce protocole vers des serveurs STUN retournent à la fois l'IP locale et l'P publique, et ces données sont lisibles avec JavaScript. Un internaute peut donc être attaqué par un simple bout de code JavaScript présent dans une page visitée.       

Il y a aussi eu nulérama, on va pas leur faire la pub.
Titre: Faille RTCPeerConnection, suite
Posté par: corrector le 30 mai 2015 à 02:37:28
https://lafibre.info/techno-du-web/la-faille-est-une-feature-webkitrtcpeerconnection/msg199495/#msg199495

Citation de: Snickerss
"Le monde entier hurle au danger du nucléaire"
==> corrector demande des sources (ou le monde entier est con, ça dépend des humeurs)

"Le monde entier hurle à la faille"
==> bon on le croit sur parole  ;D
Je ne doute pas une seconde que des gens aient très peur du nuc, et je n'ai jamais demandé une source pour prouver qu'il y a des opposants au nuc; j'ai juste dit que ces gens se trompent.

Sur la faille, il n'y a pas à se tromper ou pas. Par définition, la faille est la trahison de la confiance.

Pour le nuc aussi les gens croient que la confiance a été trahie par la promesse du risque zéro, mais cette promesse n'a jamais existée sauf dans la tête des gens qui entendent des voix, ce qui est une grande partie de la population. Mais le critère objectif est "personne n'est ou ne sera malade" et donc je me moque de ce que les gens pensent.

Dans le premier cas, il y a une mesure objective du danger. Dans le second cas, ce n'est pas clair, il n'y a pas de contrat écrit sur ce qu'un navigateur peut faire ou non.

Tout cela tendrait à montrer que les navigateurs sont plus dangereux que les centrales nucléaires.
Titre: La faille est une "feature" : webkitRTCPeerConnection
Posté par: corrector le 25 octobre 2016 à 04:11:53
On pense tous que le protocole IP est la base d'Internet mais on oublie qu'en l'état actuel, des qu'on sort du LAN on n'a plus vraiment de lien 100% IP entre 2 machines. On se retrouve avec un 'truc tordu' qui ne laisse passer que UDP et TCP et avec des restrictions assez fortes (port ouvert, adresse partagée, etc). On est tellement confronter a cela que pour beaucoup de gens ca devient la 'norme' et l'IP 'normale' du début d'Internet devient l'exception...un comble !
Oui c'est ce que je dis depuis toujours. Mais ça n'a aucun rapport avec le sujet.

Franchement et je rejoint le dev de Chrome qui parlais de ca: vivement qu'IPv6 prenne la relève qu'on se débarrasse de cet ersatz d'IP actuel qui complique toute innovation, promeut un modèle centralisé et donne un faux sentiment de sécurité (au point que des gens s'affolent qu'on communique leur IP locale sans leur dire).

Si ce 'bug/faille/whatever' de WebRTC peut être une pierre de plus pour promouvoir IPv6, j’espère qu'ils ne le corrigeront jamais ;D
Non, ça n'a aucun rapport.

Le 2eme comble dans cette histoire est que WebRTC permet un fonctionnement non centralisé des navigateurs: un lien peer to peer directe entre eux. Un truc qui devrait combler les paranos et les anti-NSA/Google/QueSaisJeEncore mais c'est pourtant eux qui se plaignent le plus de ce 'bug/faille/whatever' .... :P
Un comportement non centralisée ne nécessite pas de communiquer au monde entier ton IP privée.