Auteur Sujet: Faille RTCPeerConnection  (Lu 29697 fois)

0 Membres et 2 Invités sur ce sujet

Breizh 29

  • Client Bouygues Fibre +
  • Abonné Orange Fibre
  • *
  • Messages: 4 279
  • Guilers 29820 (29N)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #48 le: 05 février 2015 à 21:10:48 »
Qui a piqué les "louzoù" de corrector  :o
Qu'on les lui rende immédiatement.  ;D

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #49 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.

jack

  • Professionnel des télécoms
  • *
  • Messages: 1 674
  • La Madeleine (59)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #50 le: 05 février 2015 à 21:53:16 »
Non.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #51 le: 05 février 2015 à 22:41:23 »
Non quoi?

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #52 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.

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #53 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 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...



corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #54 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
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.
« Modifié: 07 février 2015 à 16:49:19 par corrector »

kgersen

  • Modérateur
  • Abonné Bbox fibre
  • *
  • Messages: 9 078
  • Paris (75)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #55 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

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

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #56 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.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #57 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.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #58 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.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #59 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?