Auteur Sujet: Faille RTCPeerConnection  (Lu 12040 fois)

0 Membres et 1 Invité sur ce sujet

corrector

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

corrector

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

corrector

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

pasbefri

  • Client FAI autre
  • *
  • Messages: 92
  • Hagondange (57)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #27 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

Damien

  • Directeur d'exploitation
  • Expert
  • *
  • Messages: 1 483
    • K-Net.fr
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #28 le: 04 février 2015 à 20:18:25 »
Un tuto pour expliquer le bouton "Editer" à Corrector ?

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #29 le: 04 février 2015 à 21:13:01 »
Plait-il?

Damien

  • Directeur d'exploitation
  • Expert
  • *
  • Messages: 1 483
    • K-Net.fr
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #30 le: 04 février 2015 à 21:15:26 »
Tu enchaîne les posts pour accentuer le bruit que tu veux faire ou pas ?

corrector

  • Invité
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #31 le: 04 février 2015 à 21:26:00 »
Aucun intérêt.

On peut revenir au sujet?

BadMax

  • Client Free adsl
  • Modérateur
  • *
  • Messages: 3 349
  • Malissard (26)
La faille est une "feature" : webkitRTCPeerConnection
« Réponse #32 le: 04 février 2015 à 21:40:40 »
C'est quoi le jeu ? énerver corrector ?

Pfff top facile...

corrector

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

corrector

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

corrector

  • Invité
webkitRTCPeerConnection + NAT
« Réponse #35 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.

 

Mobile View