Auteur Sujet: Faille RTCPeerConnection  (Lu 11135 fois)

0 Membres et 1 Invité sur ce sujet

jack

  • AS24904 Ingénieur système K-Net
  • Professionnel des télécoms
  • *
  • Messages: 1 402
  • Amiens (80)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #12 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

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #13 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.
« Modifié: 05 février 2015 à 22:50:36 par corrector »

jack

  • AS24904 Ingénieur système K-Net
  • Professionnel des télécoms
  • *
  • Messages: 1 402
  • Amiens (80)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #14 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

corrector

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

jack

  • AS24904 Ingénieur système K-Net
  • Professionnel des télécoms
  • *
  • Messages: 1 402
  • Amiens (80)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #16 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.

Marin

  • Client Bbox vdsl
  • Modérateur
  • *
  • Messages: 2 763
  • Bourgoin-Jallieu (38)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #17 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.

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

Electrocut

  • Client Bbox adsl
  • *
  • Messages: 399
  • Pont-Péan (35)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #18 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é" ;)

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #19 le: 04 février 2015 à 10:56:55 »
Qu'est-ce qu'une faille?

kgersen

  • Client Orange Fibre
  • Modérateur
  • *
  • Messages: 4 702
  • FTTH 1Gb/s sur Paris (75)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #20 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.

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #21 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?
« Modifié: 04 février 2015 à 14:19:36 par corrector »

corrector

  • Invité
Utilité du NAT
« Réponse #22 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.
« Modifié: 04 février 2015 à 18:45:40 par corrector »

corrector

  • Invité
Utilité du NAT
« Réponse #23 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...
« Modifié: 04 février 2015 à 18:45:16 par corrector »

 

Mobile View