P2P : Trident Media Guard veut polluer le streaming de flux vidéo illicites

Le 26/06/2013 à 10h39

Bon, avant de dire quoi que ce soit, je me permet de poser ici quelques question élémentaires à ceux qui s’y connaissent.

Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?

D’autre part, est-ce qu’il y a des contrôles d’intégrité sur les flux émis en streaming ? Si non, est-ce qu’on peut en mettre ? Car à ce moment-là, les données corrompues sont envoyées à /dev/null dès réception une fois détectées et, potentiellement, la méthode vendue par TMG serait inefficace.

Et enfin, avec des flux chiffrés, ils font comment ?

Aponhcet

Le 26/06/2013 à 10h39

oXis a écrit :

Je crois que c’est possible avec le client µtorrent.

je confirme

lossendae

Le 26/06/2013 à 10h40

C’est son fond de commerce il a raison. Je suis sûr que son rêve est l’éclosion lente d’un nouveau réseau pour vendre encore plus de solutions anti piratage.

Il n’y a pas de petit profits.

OlivierJ Abonné

Le 26/06/2013 à 10h41

Déposer un brevet pour un truc comme ça :-o

Surtout qu’à part TMG, qui va s’en servir ?

Et puis les fichiers qu’on télécharge et qui ne correspondent pas au nom, ça ne date pas d’hier…

garvek

Le 26/06/2013 à 10h42

Certes ça peut pourrir le streaming, mais pour les patients qui attendent le fichier complet, leur procédé ne tient pas car on le grille avec le hash fourni la plupart du temps par les sites. Alors qu’ils ne soient les fournisseurs du flux originel, je ne vois pas trop comment ça va tenir la route leur truc.

feuille_de_lune

Le 26/06/2013 à 10h44

Commentaire_supprime a écrit :

Bon, avant de dire quoi que ce soit, je me permet de poser ici quelques question élémentaires à ceux qui s’y connaissent.

Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?

D’autre part, est-ce qu’il y a des contrôles d’intégrité sur les flux émis en streaming ? Si non, est-ce qu’on peut en mettre ? Car à ce moment-là, les données corrompues sont envoyées à /dev/null dès réception une fois détectées et, potentiellement, la méthode vendue par TMG serait inefficace.

Et enfin, avec des flux chiffrés, ils font comment ?

Le théorie voudrait qu’à partir d’un certain taux, le peer qui émet les pièces corrompue soit aux final banni. Enfin ce que j’ai pu comprendre du comportement de certains client et tracker torrent.

oXis Abonné

Le 26/06/2013 à 10h44

Le bon côté le la chose c’est que pour les 500 premiers méga on aura des serveurs rapide pour nous envoyer les données " />

Commentaire_supprime

Le 26/06/2013 à 10h46

oXis a écrit :

Le bon côté le la chose c’est que pour les 500 premiers méga on aura des serveurs rapide pour nous envoyer les données " />

+1 !

Et avec un bon script kivabien, on pourra récupérer à toute blinde des données par tranche de 500 Mo !

" />" />" />" />" />

Bejarid

Le 26/06/2013 à 10h48

C’est un peu la même technique pour le P2P classique ou ils pourrissent les recherches avec des fakes.

Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.

Azariel

Le 26/06/2013 à 10h48

OlivierJ a écrit :

Déposer un brevet pour un truc comme ça :-o

Surtout qu’à part TMG, qui va s’en servir ?

Et puis les fichiers qu’on télécharge et qui ne correspondent pas au nom, ça ne date pas d’hier…

brevet pour pouvoir mettre leurs pubs dans les flux, avant que google n’y pense ou ne reprennent tout simplement le principe

Jean_Peuplus

Le 26/06/2013 à 10h50

oXis a écrit :

Je crois que c’est possible avec le client µtorrent.

pas seulement, il y en a pas mal d’autres, dont sopcast

Commentaire_supprime

Le 26/06/2013 à 10h52

Bejarid a écrit :

C’est un peu la même technique pour le P2P classique ou ils pourrissent les recherches avec des fakes.

Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.

Sans compter que s’ils emploient les mêmes IP que pour la surveillance du P2P, il suffira d’une bonne règle dans le pare-feu pour les envoyer chier…

garvek a écrit :

Certes ça peut pourrir le streaming, mais pour les patients qui attendent le fichier complet, leur procédé ne tient pas car on le grille avec le hash fourni la plupart du temps par les sites. Alors qu’ils ne soient les fournisseurs du flux originel, je ne vois pas trop comment ça va tenir la route leur truc.

feuille_de_lune a écrit :

Le théorie voudrait qu’à partir d’un certain taux, le peer qui émet les pièces corrompue soit aux final banni. Enfin ce que j’ai pu comprendre du comportement de certains client et tracker torrent.

Merci. " />

Je note au passage que pour les flux chiffrés, personne n’a répondu…

" />" />" />" />" />

ragoutoutou Abonné

Le 26/06/2013 à 10h52

A terme, les clients p2p intègreront juste un système de blacklisting plus intelligent, c’est tout… à chaque mesure sa contremesure…

canti

Le 26/06/2013 à 10h53

Commentaire_supprime a écrit :

Leur procédé, cela me rappelle une attaque type man-in-the-middle. D’où ma première question : ça ne se détecte pas, ce genre de truc ? Car en injectant les données corrompues depuis un autre point que celui de départ, on voit deux IP d’émission à l’arrivée au lieu d’une, et on peut en théorie ban celle qui fout la merde. Qu’en est-il dans la pratique ?

L’adresse IP d’émission est déclarative, c’est ton ordinateur qui, quand il complète la trame, met ton adresse IP. Tu peux lui demander de mettre l’IP que tu veux.

C’est tout a fait possible de prendre la liste des pairs qui partagent un fichier, et se faire passer pour ces pairs, et envoyer des données corrompues : au bout d’un certain temps, tu banniras alors les pairs qui auraient pus te partager ce fichier.

la solution - plus lourde - est alors de ne pas identifier ces utilisateurs par leurs adresses IP, mais par un autre moyen ( genre clé publique / clé privé)

canti

Le 26/06/2013 à 10h55

Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.

Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…

Alucard63

Le 26/06/2013 à 10h58

Ca ne sert à rien." />

tass_

Le 26/06/2013 à 13h32

ISFNoah a écrit :

Oui: tu confonds chiffrement et signature " />

=> Je pense pas que TMG s’amuserait à s’autogriller en indiquant spontanément le hash du paquet modifié au lieu du hash du paquet d’origine

Tu veux dirent que le contenu de leur bloc ne correspondrait pas au hash du bloc ? Tu veux dire que quand on dit :

“Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair”

Ca veut dire que l’application ne vérifie même pas que le contenu d’un bloc est valide par rapport au hash contenu dans ce même bloc ? L’horreur en effet xD… le streaming p2p n’est pas du tout au point si c’est le cas…

edit :et je vois pas en quoi je parle de signature… je parle bien d’un flux crypté : la source t’envoie du contenu crypté que affiches grâce à sa clé publique.

doudawak

Le 26/06/2013 à 13h34

Enyths a écrit :

C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

Ce qui est globalement une grosse connerie.

De toute manière avec les Hash ça me semble bien trop inefficient comme méthode. Je suis quasiment certain que ce n’est pas les premiers à tenter l’expérience et que si l’on cherche bien dans d’autres pays on doit trouver le même procédé.

Excuses moi, tu m’a tué. C’est pas du pipot, c’est une connerie alors =)

ragoutoutou Abonné

Le 26/06/2013 à 13h35

tass_ a écrit :

Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.

Donc si je résumes :

flux crypté => ban des sources après un nombre de blocs faux.

flux en clair => récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.

Un faille à ce raisonnement ?

Tu peux envoyer en clair des blocs signés… ça peut être moins violent pour le cpu (tu ne chiffre pas le contenu du bloc, tu fais un somme de contrôle et tu la signes avant de la rajouter dans l’entête du bloc avant de l’envoyer)… si un peer t’envoie des blocs avec une signature défectueuse, tu le met en blacklist puisqu’il était supposé faire les mêmes contrôles que toi avant de relayer les blocs. Avec un système pareil, un parasitage comme celui breveté par TMG a un impact totalement négligeable.

ISFNoah

Le 26/06/2013 à 13h35

canti a écrit :

pas de signature sans chiffrement

Dans ce sens oui, mais dans l’autre non

canti a écrit :

si ils mettent le bon hash, tu verras que le paquet est mauvais une fois télechargé, et tu ne l’afficheras pas a l’utilisateur ( et par la même occasion, tu ne le partageras pas). c’est plus du DoS que de la corruption de flux video

Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.

Youka

Le 26/06/2013 à 13h36

En gros c’est juste la corruption de fichier, mais appliquée au streaming parce que ça ne marche pas en torrent normal.

Les parties corrompues sont détectées et l’émetteur finit par être juste blacklisté par le client.

Il suffit d’ajouter un système de vérification de l’intégrité des parties “à la volée” pour régler la question…

canti

Le 26/06/2013 à 13h37

saf04 a écrit :

je ne dit pas que je sais comment le faire…

je te dis que c’est dont tmg parle dans son brevet, notamment page 4 pour evoquer la necessité d’envoyer beaucoup de blocs fiables avant pour rester un pair fiable dans les echanges.

dans la pratique, le bloc “faux” sera fiable (avec un hash et un chunk de donnée correspondant), ca sera par contre difficile de voir que cette donnée video n’est pas celle qui était prévue.

après c’est sur qu’il ne faut pas inonder le réseau de merde, sinon on t’identifie tout de suite ^^

canti

Le 26/06/2013 à 13h38

ISFNoah a écrit :

Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.

mais ca veut dire que pour déranger durablement 10000 utilisateurs, ils faut innonder d’autant leur bande passante : c’est plus du Denial of service, que de la corruption, dont on parle ici

Commentaire_supprime

Le 26/06/2013 à 13h39

ragoutoutou a écrit :

Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.

Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.

Ah ben tiens, j’allais demander si quelque chose dans ce genre était possible.

Après, pour la mise en oeuvre du zinzin, je demande à voir ça en conditions réelles. J’ai peut-être tort mais je ne suis pas convaincu de la pertinence du truc…

doudawak

Le 26/06/2013 à 13h39

tass_ a écrit :

Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.

Donc si je résumes :

flux crypté => ban des sources après un nombre de blocs faux.

flux en clair => récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.

Un faille à ce raisonnement ?

Te prends pas trop la tete avec un cryptage des échanges p2p. Ca veut simplement dire qu’il y a une couche réseau supplémentaire, ca ne change rien à la nature de l’échange.

Tous les pairs qui s’échagent doivent pouvoir communiquer avec le meme “langage”. aussi bien en clair qu’en crypté. La seule différence, c’est qu’un man in the middle est pas possible en crypté.

La, le brevet dit pas “on se mets entre les 2 pairs”, il dit “je me fais passer pour un pair”. ne confonds pas les 2

doudawak

Le 26/06/2013 à 13h40

Khalev a écrit :

Et?

Cool TMG enverra ses faux blocs de façon sécurisé. Wouhou…

C’est pile ce que je viens de dire, y a pas raison de parler de cryptage ici… c’était pour expliquer le concept rapidement, pas donner rason a TMG.. OMG =)

ISFNoah

Le 26/06/2013 à 13h44

tass_ a écrit :

edit :et je vois pas en quoi je parle de signature… je parle bien d’un flux crypté : la source t’envoie du contenu crypté que affiches grâce à sa clé publique.

La source chiffre le contenu avec ta clé publique et tu la déchiffres avec ta clé privée. Mais bon s’il n’y a pas de signature, ça sert à rien pour détecter les paquets volontairement altérés.

canti a écrit :

mais ca veut dire que pour déranger durablement 10000 utilisateurs, ils faut innonder d’autant leur bande passante : c’est plus du Denial of service, que de la corruption, dont on parle ici

Oui, TMG tout en finesse ;)

TaigaIV

Le 26/06/2013 à 13h48

Quel est la différence entre cette histoire et avoir une milice privée qui patrouillerait les rues pour faire régner sa loi ?

Une chose est certaines, on a toujours pas de pétrole.

tass_

Le 26/06/2013 à 13h52

ISFNoah a écrit :

Effectivement.. reste qu’il faut tout de même recevoir le hash d’un nombre suffisant d’autres sources et ce avant même de télécharger le paquet, donc pour du streaming la latence peut vite s’accumuler, comme ça.

Je sais pas, je suis pas assez calé pour le déterminer…

Après on peut régler le nombre de hash à récupérer en fonction de la latence.

canti

Le 26/06/2013 à 13h52

TaigaIV a écrit :

Quel est la différence entre cette histoire et avoir une milice privée qui patrouillerait les rues pour faire régner sa loi ?

Une chose est certaines, on a toujours pas de pétrole.

quand ils te chopent, ca fait moins mal au nez " />

TaigaIV

Le 26/06/2013 à 13h56

canti a écrit :

quand ils te chopent, ca fait moins mal au nez " />

Enfin la ils sont partis pour t’éclater les yeux, je ne suis pas certains que ce soit mieux. " />

tass_

Le 26/06/2013 à 13h59

doudawak a écrit :

Te prends pas trop la tete avec un cryptage des échanges p2p. Ca veut simplement dire qu’il y a une couche réseau supplémentaire, ca ne change rien à la nature de l’échange.

Tous les pairs qui s’échagent doivent pouvoir communiquer avec le meme “langage”. aussi bien en clair qu’en crypté. La seule différence, c’est qu’un man in the middle est pas possible en crypté.

La, le brevet dit pas “on se mets entre les 2 pairs”, il dit “je me fais passer pour un pair”. ne confonds pas les 2

Pour la partie “cryptée” je répondais à je sais plus qui qui disait que TMG pouvait se faire passer pour un utilisateur lambda du réseau et donc échanger normalement avec nous sans “casser” un quelconque cryptage.

Je dis donc bien qu’en cas de cryptage TMG peut se faire passer pour un des pairs mais pas pour un pair de confiance (spoof l’id d’un utilisateur connu) et que donc le ban pur et dur n’aurait pas d’effet de bord sur des sources fiables.

Alors que dans un échange non crypté, usurper l’id d’un utilisateur fiable est faisable.

Neeko

Le 26/06/2013 à 10h34

On leur dit que streamer en P2P on sait pas encore faire ?

" />

oXis Abonné

Le 26/06/2013 à 10h35

Neeko a écrit :

On leur dit que streamer en P2P on sait pas encore faire ?

" />

Je crois que c’est possible avec le client µtorrent.

t0FF

Le 26/06/2013 à 10h38

oXis a écrit :

Je crois que c’est possible avec le client µtorrent.

C’est sûr, et ça marche très bien ! " />

malock

Le 26/06/2013 à 11h26

alf a écrit :

le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …

Ah bah voilà, c’est juste la donnée qu’il me manquait…

Merci.

camszdzs

Le 26/06/2013 à 11h27

malock a écrit :

Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?

il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?

maaaaaaiiiiiis tes questions sonnent un peu bizzarre là " />:P si t’étais pas abonné, je te soupçonnerais de bosser chez eux " />

sinon heuuu donc le plan c’est de diffuser des matériaux sous copyright pour embêter ceux qui diffusent des matériaux sous copyright ?

et sinon sinon on a le droit de breveter juste une idée ? ou ils ont déjà un logiciel tout prêt et c’est ça qu’ils ont breveté ?

Tim-timmy

Le 26/06/2013 à 11h28

malock a écrit :

Ah bah voilà, c’est juste la donnée qu’il me manquait…

Merci.

cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.

Au passage c’est dit dès le début du brevet, que dans le cas du streaming les réseaux p2p désactivaient ce genre de sécurité inutilisable, et donc ouvraient la faille à leur invention

Alameda

Le 26/06/2013 à 11h31

Je me pose une grosse question où TMG va t il choper les vrais données du début ? Ils vont demander un accès privilégier au labellisé PUR ? Si oui on ne risque rien l’offre est tellement pauvre que ça ne se verras même pas.

Accès aux serveurs des ayant-droits ? Si oui, ça risque d’être casse gueule, je vois bien le coup que certains petit malins vont remonter jusqu’à TMG puis chopper les infos sur les serveurs des ayant-droits.

Quand à la dernière solution, qui consiste à récupérer le film avant de pourrir les flux, ils ont pas intérêt à se faire chopper par eux même.

Impatient de voir ça.

/popcorn

fitfat

Le 26/06/2013 à 11h31

saf04 a écrit :

les gars faudrait un peu se reveiller quand meme " />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.

Ils ont un problème dans leur algo de détection, dans ce cas.

saf04

Le 26/06/2013 à 11h32

Tim-timmy a écrit :

on parle de streaming live, donc impossible de les connaître avant leur génération

sous torrent avant de lancer ton streaming, il te faut le fichier torrent. qui contient un hash général ou chaque piece recue va etre comparée et rejetée si fausse ou corrompue.

alf

Le 26/06/2013 à 11h33

Tim-timmy a écrit :

on parle de streaming live, donc impossible de les connaître avant leur génération

Tu parle de streaming live, mais pas l’article. Qui plus est, qui irait pourrir un streaming live … a part pour casser les pieds des honnêtes gens ?

L’utilisation de streaming live c’est pas du tipiak a ce que je sache (ça doit bien exister en tipiak, mais ça doit être plutôt marginal).

vince120 Abonné

Le 26/06/2013 à 11h38

jb18v a écrit :

+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?

Si, mais pas pour les forces de l’ordre ou l’armée…

…ou la milice privée.(c’est le cas de TMG):S

Encore que… les flics en “infiltration” peuvent être amené à “apater” des gens mais si la justice décide que l’apatage a été trop loin et est devenu de l’incitation alors un bon avocat pourra faire sauter l’accusation…

Enfin, crypté ou non, les hashs (qui ne sont pas transmis en même temps que les paquets mais qui sont dans la “description” du torrent) permettent d’identifier un paquet faux mais on ne saura pas si c’est volontaire ou non. Pour chaque paquet réseau (et il en faut N pour transmettre un morceau de fichier P2P) il y a un contrôle (style parité ou somme de contrôle) de bas niveau qui permet de savoir si les données ont été corrompues au niveau de la couche technique (sur les fils)

malock

Le 26/06/2013 à 11h38

Tim-timmy a écrit :

cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.

Euh ok. Bin j’ai pas compris ton commentaire… (c’est que j’y connais que dalle hein, on est d’accord)

Streaming-live ? C’est à dire ?

Moi ce que je crois savoir, c’est que les spec’ du P2P indique que l’échange de paquet est régi par la notion de rareté (on distribue d’abord les paquets les plus rares). Il y a aussi d’autre façon de faire : distribuer les paquets dans l’ordre (je “sais” ça car j’ai “bricolé” un bout de code avec un pote qui voulait se faire du streaming via P2P). Avec la seconde solution, on se retrouve à streamer via P2P non ?

Dans tous les cas, il faut tout de même récupérer un tracker dans lequel l’ensemble des paquets constituant le fichier final est indiqué (ainsi que leur hash) non ?

camszdzs a écrit :

maaaaaaiiiiiis tes questions sonnent un peu bizzarre là " />:P si t’étais pas abonné, je te soupçonnerais de bosser chez eux " />

Non non ! J’y connais pas grand chose et je suis juste intéressé par être un peu moins ignorant sur le sujet " />

Tim-timmy

Le 26/06/2013 à 11h38

alf a écrit :

Tu parle de streaming live, mais pas l’article. Qui plus est, qui irait pourrir un streaming live … a part pour casser les pieds des honnêtes gens ?

L’utilisation de streaming live c’est pas du tipiak a ce que je sache (ça doit bien exister en tipiak, mais ça doit être plutôt marginal).

. L’idée est ainsi de s’intercaler dans ces échanges et de pourrir les flux P2P streamés provenant par exemple des chaînes TV payantes. Comment ? En plaçant des images figées, déjà diffusées ou saccadées, voir des publicités…ou des messages d’avertissement.

après j’y peux rien si vous ne lisez pas les articles, ni les brevets cités :p Ils y citent clairement les réseaux IPTV comme cibles, genre sopcast, PPLive ou autres… Et si, le streaming live ça permet de chopper par exemple les chaines payantes pour le sport, en général … voire pour tout le reste en fait…

2show7

Le 26/06/2013 à 11h40

Les FAI ayant droits, ça ne vous aide pas plus ? Gros débit sur une IP, surveillance approfondie

DarKCallistO

Le 26/06/2013 à 11h40

Tim-timmy a écrit :

on parle de streaming live, donc impossible de les connaître avant leur génération

Non,on parle de Streaming via les réseau p2p,si tu veux corrompre une vidéo en streaming live déjà ça passe rarement par des protocole de p2p,mais plutôt sur des infrastructure centralisé et deuxio j’ai jamais vu ou entendu parler d’une méthode de transmission de streaming live utilisant des réseaux acentré comme le p2p

Tim-timmy

Le 26/06/2013 à 11h41

DarKCallistO a écrit :

Non,on parle de Streaming via les réseau p2p,si tu veux corrompre une vidéo en streaming live déjà ça passe rarement par des protocole de p2p,mais plutôt sur des infrastructure centralisé et deuxio j’ai jamais vu ou entendu parler d’une méthode de transmission de streaming live utilisant des réseaux acentré comme le p2p

non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.

alf

Le 26/06/2013 à 11h43

Tim-timmy a écrit :

après j’y peux rien si vous ne lisez pas les articles, ni les brevets cités :p Ils y citent clairement les réseaux IPTV comme cibles, genre sopcast, PPLive ou autres… Et si, le streaming live ça permet de chopper par exemple les chaines payantes pour le sport, en général … voire pour tout le reste en fait…

OK, mea culpa, j’ai sauté ce passage :)

Il me semblait juste que cette utilisation était marginale.

Mais je me rappelle effectivement d’un pote qui regardait des matchs de sport dans un player video p2p.

La qualité étant vraiment médiocre, je ne pensait pas que ça puisse être vraiment utilisé par tant de personnes que ca …

danyel76

Le 26/06/2013 à 11h47

très gentil ce thierry lhermitte ….. enfin " />

ce type, je l ‘ ai banni.

saf04

Le 26/06/2013 à 11h47

par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?

Tim-timmy

Le 26/06/2013 à 11h48

saf04 a écrit :

par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?

temps réel … regarde ce que fait sopcast par exemple.

pti_pingu

Le 26/06/2013 à 11h49

Si pour cela, les FAIs pouvaient également brider, ce serait pas mal " />

canti

Le 26/06/2013 à 11h49

Tim-timmy a écrit :

cf mon commentaire ci-dessus, ce n’est pas du tout applicable dans le cas abordé, on ne connait pas le contenu du flux streamé, c’est le principe.

Au passage c’est dit dès le début du brevet, que dans le cas du streaming les réseaux p2p désactivaient ce genre de sécurité inutilisable, et donc ouvraient la faille à leur invention

du stream P2P en live, je n’avais jamais entendu parler, c’est interessant…

pour moi la solution sera de s’assurer de la fiabilité d’un peer, et le banir au besoin… mais c’est vrai que se pose alors la question d’identification de ce “faussaire”

camszdzs

Le 26/06/2013 à 11h51

corrigez moi si je me trompe mais à la lecture du brevet tout ce dont ils parlent c’est leur idée, en fait ?

brevet basé sur l’idée super novatrice de pourrir les réseau p2p avec des contenus qui ne sont pas ce que l’utilisateur croit…wow…

on peut rajouter le patent trolling à la liste de leur pechés:o

alors au final c’est plutôt très positif, ça va surtout compliquer les tentatives d’autres acteurs de pourrir les réseaux " />

mais on devrait pas avoir le droit de poser un brevet pour une idée, surtout pour une idée qui a rien de neuve. c’est ce qui me gène le plus au final dans cette actu :(

saf04

Le 26/06/2013 à 11h52

Tim-timmy a écrit :

temps réel … regarde ce que fait sopcast par exemple.

ha ok je comprend beaucoup mieux l’article maintenant. merci.

alf

Le 26/06/2013 à 11h52

saf04 a écrit :

par contre un truc que je pige pas…

quand l’article parle de flux streamés provenant de chaines tv payantes.

on est en temps reel (ca existe ??) ou en dans le cas de streaming p2p d’emissions ou series déjà diffusées ?

c’est du temps réel décalé de quelques secondes a plusieurs minute.

Marc4444 Abonné

Le 26/06/2013 à 11h55

saf04 a écrit :

les gars faudrait un peu se reveiller quand meme " />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.

moi aussi " />

Bejarid

Le 26/06/2013 à 11h57

saf04 a écrit :

les gars faudrait un peu se reveiller quand meme " />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.

Ces solutions font pas dans la dentelle hein…

Les gars qui les maintiennent arrivent plutot bien à suivre les IPs utilisé par TMG et cie, et après, ils se font pas chier, ils bloquent un range d’ip complet.

Clairement ils bloquent des innocents dans l’affaire mais n’en ont cure, et le fait est que ça marche (même si ça réduit ton nombre de pair sur lequel tu peux pomper). Bien sur faut updater ça régulièrement :)

Neeko

Le 26/06/2013 à 11h57

oXis a écrit :

Je crois que c’est possible avec le client µtorrent.

Ah, c’est allé super vite alors… encore l’année dernière ya un mec qui a sorti une idée pour y arriver… et plus de nouvelles depuis.

Edit :https://korben.info/bittorrent-live.html

Mouais, apparemment, ya encore du boulot, c’est pas en se focalisant là dessus qu’ils vont avancer… Je doute que beaucoup de gens l’utilisent.

DarKCallistO

Le 26/06/2013 à 11h58

Tim-timmy a écrit :

non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.

Oui,donc une utilisation quasi marginal dans le p2p.

Groumfy

Le 26/06/2013 à 11h59

Mouais, et pendant ce temps là, le DDL…

Khalev

Le 26/06/2013 à 11h59

Tim-timmy a écrit :

non.

cf l’article, la source (page 3, donc l’introduction, elle est même en français si ça vous fait peur), ou mon commentaire avant . Bon aprem.

+1 d’ailleurs :

“L’invention tire parti du fait que dans les réseaux pair à pair diffusant du contenu vidéo en streaming, la fenêtre de lecture que chaque pair cherche à remplir doit être remplie dans une durée donnée qui est généralement très courte, étant par exemple de l’ordre de 2 à 3 minutes. Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair, du fait de leur coût en temps et en occupation du processeur du terminal associé à chaque pair du réseau”.

Tant qu’à faire autant mettre LE truc sur lequel repose toute l’“invention”.

Cette condition n’est pas remplie, leur “invention” tombe à l’eau. D’ailleurs c’est tellement une invention que le contre existe déjà et est déjà implémenté pour les torrents “classiques”… Ils profitent juste d’une limitation technique dû au type de contenu pour breveter une technique qui existait il y a + de 10 ans quand les premiers logiciels p2p sont sortis (et qu’il n’y avait pas de contrôle d’intégrité justement).

De plus pour moi c’est un brevet logiciel leur truc. Les 4 dernières pages avant les revendications sont juste un algo écrit en français (donc chiant à lire). Et avant ça explique les conditions nécessaires pour que ça fonctionne et les utilisations que ça pourrait avoir.

Et je donne un bon point à celui qui trouve le point “c’est pour protéger les petits nenfants” dans le brevet.

HarmattanBlow

Le 26/06/2013 à 12h07

Commentaire_supprime a écrit :

Je note au passage que pour les flux chiffrés, personne n’a répondu…

Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).

Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.

AntonyToku

Le 26/06/2013 à 12h08

Alucard63 a écrit :

Ca ne sert à rien." />

Pourquoi une pub m’agresse quand je clique sur ton lien?

Commentaire_supprime

Le 26/06/2013 à 12h10

fitfat a écrit :

Ils ont un problème dans leur algo de détection, dans ce cas.

+1. Parce qu’un VPN, ça fait bien relais de données dans les deux sens, mais pour le passer afin d’appliquer des protocoles custom sur le réseau, ça me paraît assez sportif.

Mais chut, on ne va pas dire qu’il suffit d’une bonne règle de pare-feu pour envoyer chier l’usine à gaz mise en place par TMG, surtout de la part des propagandistes des zéyandrouah…

Commentaire_supprime

Le 26/06/2013 à 12h13

HarmattanBlow a écrit :

Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).

Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.

Question bête : le chiffrement, comment est-ce qu’ils le cassent ?

C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B. Et X, il fait comment son man-in-the-middle dans ce cas s’il n’a pas la clef de déchiffrement des données~? Et surtout, comment peut-il savoir que les données chiffrées qu’il voit passer sont du P2P, et non des ordres de vente boursiers, par exemple ?

ISFNoah

Le 26/06/2013 à 12h49

saf04 a écrit :

y’a aucun chiffrement dans l’histoire…

tmg se fait passer pour un utilisateur lamba. il t’envoie deux trois bon bout de fichier, puis un moisi.

si tu as de la chance, ton bout moisi est dans le buffer du logiciel et il est rejeté, ce qui te ralenti. sinon il est en affichage temps reel et tu vois le bout moisi avant qu’il ne soit vérifié.

y’a aucun cryptage, cassage de truc ou chais pas quoi.

On pourrait par contre je pense assez aisément imaginer de signer les paquets: par exemple, chaque client du réseau P2P dispose d’une clé (genre OpenPGP) et signe les paquets qu’il envoie. S’il s’avère que le paquet est véreux, un gros mauvais point, sinon un bon point. Si un client a un trop mauvais ratio, ses envois sont ignorés voire il est complètement bloqué.

Pour aller un peu plus loin on peut aussi imaginer que, en parrallèle des paquets de contenus, l’ensemble des clients échangent des info de checksum des paquets et leurs stats concernant les mauvais clients (qui seraient pondérées par la réputation +/- ajustées mauellement).

ragoutoutou Abonné

Le 26/06/2013 à 12h50

Commentaire_supprime a écrit :

En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.

Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…

Même s’ils perturbent du P2P ‘illégal’, ils seraient en violation de la loi. C’est un peu comme activer un brouilleur près d’un club d’aéromodélisme sous prétexte que des modèles réduits ont volé en dehors des heures autorisées.

saf04

Le 26/06/2013 à 12h51

ISFNoah a écrit :

invention rigolote…

c’est déjà comme ca que ca marche depuis le debut du p2p …

canti

Le 26/06/2013 à 12h51

doudawak a écrit :

C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :

le fichier correspond au hash, donc il n’a pas bougé d’un bit

le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk

Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.

attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.

c’est justement là que c’est difficile… enfin bon, c’est pas mon mode de consommation, donc il peuvent s’attaquer à ça " />

saf04

Le 26/06/2013 à 12h53

canti a écrit :

attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.

faudrait penser a lire les commentaires…

que cela soit en streamé ou pas, bitorrent verifie chaque morceau recu grace a un hash contenu dans le fichier de lancement.

ISFNoah

Le 26/06/2013 à 12h58

saf04 a écrit :

c’est déjà comme ca que ca marche depuis le debut du p2p …

Ah ? Les paquets ont toujours été signés depuis le début du P2P ? Mouais, je suis dubitatif… " />

Khalev

Le 26/06/2013 à 12h58

canti a écrit :

attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.

c’est justement là que c’est difficile… enfin bon, c’est pas mon mode de consommation, donc il peuvent s’attaquer à ça " />

Tu fais du 2 parmis 3.

Tu demandes 3 hash du même bloc à 3 clients différents et tu télécharges le bloc chez un de ceux qui à un hash que tu retrouves au moins 2 fois. Faut juste voir les délais que ça implique au niveau du calcul du hash. Après on a pas besoin non plus du plus gros hashage existant. Il ne conserve son intérêt que pendant 20 minutes grand max dans le cas d’un streaming live.

canti

Le 26/06/2013 à 12h58

saf04 a écrit :

faudrait penser a lire les commentaires…

que cela soit en streamé ou pas, bitorrent verifie chaque morceau recu grace a un hash contenu dans le fichier de lancement.

oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….

on parle de stream live, donc tu n’a pas de fichier de lancement contenant les hash attendues, parceque l’expéditeur ne sait pas ce qui va arriver

le “stream” de bittorent, et juste une lecture au fur et a mesure d’un fichier connu, pas la retransmition d’une chaine de TV

ragoutoutou Abonné

Le 26/06/2013 à 12h59

canti a écrit :

attention, on parle de P2P stremé en live, donc difficile de connaitre le “hash juste”.

le hash juste par bloc est spécifié dans le fichier .torrent

dès que tu es en possession de celui-ci, tu es capable de détecter les informations incorrectes. Dès lors qu’un host enverrait massivement des blocs erronés, il pourrait être blacklisté par un client un peu intelligent.

canti

Le 26/06/2013 à 13h01

ragoutoutou a écrit :

le hash juste par bloc est spécifié dans le fichier .torrent

dès que tu es en possession de celui-ci, tu es capable de détecter les informations incorrectes. Dès lors qu’un host enverrait massivement des blocs erronés, il pourrait être blacklisté par un client un peu intelligent.

pas si tu stream en live, l’expéditeur ne connait pas le contenu du fichier qu’il va streamer au moment où il génére le fichier torrent ( on en parlait au début, vous débrquez les mecs ? ^^ )

Enyths

Le 26/06/2013 à 13h02

doudawak a écrit :

C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :

le fichier correspond au hash, donc il n’a pas bougé d’un bit

le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk

Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.

Le principe du p2p c’est justement d’aller choper les infos là où elles sont dispo ! TMG ou ton voisin, meme combat.

Ca sent bien le pipot quand meme ce brevet

C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

Ce qui est globalement une grosse connerie.

De toute manière avec les Hash ça me semble bien trop inefficient comme méthode. Je suis quasiment certain que ce n’est pas les premiers à tenter l’expérience et que si l’on cherche bien dans d’autres pays on doit trouver le même procédé.

saf04

Le 26/06/2013 à 13h03

canti a écrit :

oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….

et si on parle pas de bittorrent on parle de quoi alors ?

de la technologie d’echange visée par ce brevet ?

ho zut c’est bittorrent.

Khalev

Le 26/06/2013 à 13h05

Enyths a écrit :

C’est pas du pipeau, ils partent sûrement sur le postulat que les échanges P2P ne sont pas protégés et tolèrent peu les erreurs.

Ce qui est globalement une grosse connerie.

Dans le brevet c’est LA condition sur laquelle tout repose:

“L’invention tire parti du fait que dans les réseaux pair à pair diffusant du contenu vidéo en streaming, la fenêtre de lecture que chaque pair cherche à remplir doit être remplie dans une durée donnée qui est généralement très courte, étant par exemple de l’ordre de 2 à 3 minutes. Cette contrainte temporelle a pour conséquence la faiblesse, voire la non-existence des mécanismes de vérification de l’origine des blocs reçus et de leur validité dans de tels réseaux pair à pair, du fait de leur coût en temps et en occupation du processeur du terminal associé à chaque pair du réseau”.

canti

Le 26/06/2013 à 13h06

saf04 a écrit :

et si on parle pas de bittorrent on parle de quoi alors ?

de la technologie d’echange visée par ce brevet ?

ho zut c’est bittorrent.

on parle de techno comme sopcast, qui stream du temps reel.

le protocole est surement proche de BT, mais ne peux pas utiliser un fichier torrent pour déclarer les hash par chunk.

ragoutoutou Abonné

Le 26/06/2013 à 13h07

canti a écrit :

oui, mais on ne parle pas de bittorent, faudrait penser a lire les commentaires….

on parle de stream live, donc tu n’a pas de fichier de lancement contenant les hash attendues, parceque l’expéditeur ne sait pas ce qui va arriver

Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.

Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.

caoua

Le 26/06/2013 à 13h08

M. Thierry Lhermitte, tu me feras décidément toujours rire, car peu importe la casquette que tu revêts (acteur, financeur de tmg, …) elles me font vraiment toute rire.

" />

Sacré rigolo va (dis je en lui tapotant une tape amicale sur le dos)

misterB

Le 26/06/2013 à 10h59

Neeko a écrit :

On leur dit que streamer en P2P on sait pas encore faire ?

" />

On te dis que ça se fait bcp " />" />

même les solution légale comme Spotify le fait " />

Stargateur

Le 26/06/2013 à 11h05

" /> mais ça sert à rien…" />

2show7

Le 26/06/2013 à 11h05

Si tous les pays font une queue d’attente pour contrôler youtube avec de multiples contrôles automatisés, ça ne m’étonne plus de voir qu’un tiers, quelque soit le streaming, une seule vidéo " /> et parfois attendre, ou clicker sur une position du temps différente, avant de voir la suite, par ce qu’en ayant 8gb de ram et bien ça rame le streaming sur Youtube, alors qu’avant c’était nickel (faut pas s’étonner que certains téléchargent en quantité, ils peuvent le voir ensuite sans coupure " />" /> (aux Ralentisseurs)

tazvld Abonné

Le 26/06/2013 à 11h09

Il me semble en effet que c’est quelque chose qui est prévu dans le protocole bittorrent en dévaluant les pairs qui envoient des paquets non valides. A ceci, une solution de type PeerBlock rendrait leur “solution” totalement inefficace. Ca sent surtout l’entubage d’administratifs car d’un point de vu technique, c’est inefficace (ou plus simplement de la poudre aux yeux pour justifier un nouveau contrat)

Constance Abonné

Le 26/06/2013 à 11h09

C’est toujours sympa de pourrir le réseau et générer du trafic pour de la merde.

C’est pas interdit ce genre de pratique ? En tout cas ça devrait…

tazvld Abonné

Le 26/06/2013 à 11h14

2show7 a écrit :

Si tous les pays font une queue d’attente pour contrôler youtube avec de multiples contrôles automatisés, ça ne m’étonne plus de voir qu’un tiers, quelque soit le streaming, une seule vidéo " /> et parfois attendre, ou clicker sur une position du temps différente, avant de voir la suite, par ce qu’en ayant 8gb de ram et bien ça rame le streaming sur Youtube, alors qu’avant c’était nickel (faut pas s’étonner que certains téléchargent en quantité, ils peuvent le voir ensuite sans coupure " />" /> (aux Ralentisseurs)

Qui à un traducteur ?

J’ai cru voir le mot youtube dans ce charabia : youtube n’est pas en P2P donc aucunement touché par cette solution

Tu auras beau avoir toute la ram du monde, youtube n’ira pas plus vite, c’est le “réseau de tuyaux” qui est à mettre en cause.

jb18v

Le 26/06/2013 à 11h14

+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?

malock

Le 26/06/2013 à 11h15

canti a écrit :

Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.

Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…

Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?

il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?

alf

Le 26/06/2013 à 11h19

canti a écrit :

Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.

Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…

En effet, et ca s’apelle une collision, et c’est pas facile a trouver normalement ca " />

Inny Abonné

Le 26/06/2013 à 11h21

Peerblock, et votre streaming est PUR… de toute pollution de TMG. " />

saf04

Le 26/06/2013 à 11h22

Bejarid a écrit :

Mais des solutions type PeerGuard les garderont à distance sans soucis, donc je doute de l’efficassité réelle de la manoeuvre.

les gars faudrait un peu se reveiller quand meme " />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.

alf

Le 26/06/2013 à 11h23

malock a écrit :

Je suis assez intéressé par ce que tu nous dis là.

Je ne connais pas plus que ça les spec’ du P2P. Du coup, comment ça fonctionne globalement ?

il y a d’abord un échange de hash ? (“Voici le hash du paquet que je vais t’envoyer”. “Ok, bien reçu”. “Voici maintenant le paquet”.). Ceci pour chaque paquet ?

Si le hash est transmis directement avec le paquet (c’est une partie des données), il devient tout à fait inutile non ? (Je modifie les données de la trame, je recalcule le hash et j’envoie. Lorsque le client va comparer le hash et celui qu’il a calculé à partir de données, ce sera le même…)

dans ce cas ici, ne pourrions nous pas supposer un mécanisme comme suit : des premiers “vrais” paquets sont transmis par des IP. Là, TMG s’invite dans l’envoie des paquets (“moi moi moi, j’en ai, je peux en envoyer!”) : TMG prend des paquets bidons (qui ne correspondent donc pas au fichier souhaité), génère le hash et envoie le bazar. Cela devrait rouler non ?

le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …

Tim-timmy

Le 26/06/2013 à 11h23

alf a écrit :

En effet, et ca s’apelle une collision, et c’est pas facile a trouver normalement ca " />

euh oui, mais dans le cas du streaming live, tu peux pas vraiment prédire les hash dans le futur, donc le hash sert juste à valider le paquet courant, non? dans ce cas n’importe quelle donnée hashée correctement sera valide, même si elle fait foirer la vidéo derrière en rajoutant un sale bruit dedans.

Il faudrait faire un système de majorité des hashs entre plusieurs fournisseurs en live pour éliminer ceux qui divergent, mais ça peut impacter l’aspect temps réel du streaming, et rajouter des données à échanger …

alf a écrit :

le hash des blocks est contenue dans le fichier torrent, donc a moins de corrompre le torrent …

on parle de streaming live, donc impossible de les connaître avant leur génération

saf04 a écrit :

les gars faudrait un peu se reveiller quand meme " />

tmg ont eu des ip fixes pendant leur époque de tests.

apres ils sont passés aux vpns.

nan mais chut, ça me fait toujours marrer de voir commentaire supprimé répéter en boucle l’inverse en mode méthode coué :p

2show7

Le 26/06/2013 à 11h25

tazvld a écrit :

Qui à un traducteur ?

J’ai cru voir le mot youtube dans ce charabia : youtube n’est pas en P2P donc aucunement touché par cette solution

Tu auras beau avoir toute la ram du monde, youtube n’ira pas plus vite, c’est le “réseau de tuyaux” qui est à mettre en cause.

Si tu suis tout ce qui se dit ici, je comprends, mais qu’a dit Hadopi, après le P2P, ce serait le streaming, qu’ils le fassent sur du P2P ou ailleurs, c’est pareil non ? (ils n’ont pas spécifié que sur le P2P que je sache)

Commentaire_supprime

Le 26/06/2013 à 11h25

jb18v a écrit :

+1, c’est pas illégal de brouiller une transmission, quelle qu’elle soit ?

En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.

Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…

fitfat

Le 26/06/2013 à 11h25

Si je comprends l’idée, ils précalculent une modif sur un shunk de sorte que sont hash ne soit pas altéré puis balance ce shunk corrompu sur le réseau a des pairs qui le retransmettront à d’autres (vu que le hash ne change pas, les clients ne devrait y voir que du feu) ?

Je dois avoir zapper quelque chose, nan ?

saf04

Le 26/06/2013 à 12h15

Khalev a écrit :

Et je donne un bon point à celui qui trouve le point “c’est pour protéger les petits nenfants” dans le brevet.

“Parmi ces chaines télévisées, certaines peuvent etre a accées protégé, par exemple des droits d’accés payants ou par la souscription à un abonnement payant ou non. Le contenu vidéo que le pair cherche a récupérer peut etre diffusé en streaming sur une de ces chaines télévisées.”

en fait c’est pour pas que ton fiston il streame le premier samedi du mois…

canti

Le 26/06/2013 à 12h20

HarmattanBlow a écrit :

Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).

Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.

non, tu parles d’identification de pirate, alors que ce n’est pas le sujet de la news (qui est plus la dégradation du P2P).

Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime. leurs attaques se résume alors à du DoS (ils surcharges ta connection, et c’est cher à faire pour des millions de “pirates”)

saf04

Le 26/06/2013 à 12h20

C_S je te la fait facon courte:

on est dans le cas d’un streaming ou la donnée arrive et est quasiment utilisée en temps reel.

soit les données ont le temps d’etre verifiées et rejetées et cela crée un ralentissement enorme si c’est fait a grande echelle.

soit la donnée est lue avant d’etre verifiée et la tu affiches ce que tu veux, le temps que la verification des données interviennent. mais ce laps de temps n’est valable vraiment que sur quelques secondes maxi.

donc bref je sens plutôt leur truc pour ralentir les flux et donc la qualité des streamings. mais le coup de leur message, ca marchera une fois sur mille au bas mot…

edit: canti t’as tout faux.

tass_

Le 26/06/2013 à 12h24

HarmattanBlow a écrit :

Le principe est de se faire passer pour un utilisateur normal. Tu discuteras donc avec eux en crypté, et ils t’enverront des données fausses en crypté. Ce qui te fait une belle jambe, comme avec Hadopi (tu discutes avec le faux demandeur de Twilight 12 en crypté, lequel note sagement ton adresse IP pendant que tu lui envoies en crypté la preuve que tu partages illégalement ce film).

Le cryptage ne sert qu’à éviter que ton FAI ne détecte un protocole P2P et lui assigne une priorité plus basse. Ce qui n’est pas utile avec tous les FAI. Si ton FAI ne fait pas cela, c’est juste un moyen de ralentir ta connexion sans t’offrir aucune sécurité.

Oui enfin cet état de fait est assez facile à résoudre avec des tiers de confiance… Crypter c’est bien, s’assurer qu’on discute en crypté avec la bonne personne c’est mieux.

Bref rien de non contournable ni de définitif.

Commentaire_supprime

Le 26/06/2013 à 12h29

saf04 a écrit :

C_S je te la fait facon courte:

on est dans le cas d’un streaming ou la donnée arrive et est quasiment utilisée en temps reel.

soit les données ont le temps d’etre verifiées et rejetées et cela crée un ralentissement enorme si c’est fait a grande echelle.

soit la donnée est lue avant d’etre verifiée et la tu affiches ce que tu veux, le temps que la verification des données interviennent. mais ce laps de temps n’est valable vraiment que sur quelques secondes maxi.

donc bref je sens plutôt leur truc pour ralentir les flux et donc la qualité des streamings. mais le coup de leur message, ca marchera une fois sur mille au bas mot…

Eh bien, merci pour la précision " />

Car tout chiffrement nécessite forcément des cycles processeur et du temps de traitement et, dans le cadre de flux vidéo, faire ça en temps réel, c’est un poil tendu…

Après, pour la mise en application de la solution de TMG et, surtout, pour son pouvoir de nuisance effectif, je demande à voir en conditions réelles avant d’en dire quoi que ce soit de plus…

sebtx Abonné

Le 26/06/2013 à 12h30

Ah ouai ils veulent polluer le P2P ?

Ca me ferait marrer que quelqu’un dépose un gros tas de lisier devant leurs locaux, histoire de les polluer un peu eux aussi " />

HarmattanBlow

Le 26/06/2013 à 12h30

Commentaire_supprime a écrit :

Question bête : le chiffrement, comment est-ce qu’ils le cassent ?

C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B.

Non, il s’agit de P2P. Quand tu regardes une vidéo en streaming depuis le site machin, tu reçois les données de machin mais aussi des autres utilisateurs qui regardent le même contenu (même chose sous Steam, sous le Blizzard Downloader et compagnie).

Ils ne se font donc pas passer pour un utilisateur normal du réseau.

canti a écrit :

Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime.

En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?

Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.

Il y a peut-être un problème légal. Il n’y a aucun problème technique.

tass_ a écrit :

Oui enfin cet état de fait est assez facile à résoudre avec des tiers de confiance… Crypter c’est bien, s’assurer qu’on discute en crypté avec la bonne personne c’est mieux.

Mais comment un tiers de confiance peut-il techniquement garantir la légitimité d’un utilisateur parmi des centaines de millions ? Mettre un place un système de “délation” dans les clients (“tel client est peut-être un pollueur”) ? Ce mécanisme peut lui-même être exploité pour nuire au réseau.

Rien de définitif, non, mais rien de trivial à combattre et une course aux armements en perspective. Enfin, si TMG s’y met vraiment, ce dont je doute.

tass_

Le 26/06/2013 à 12h36

HarmattanBlow a écrit :

En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?

Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.

Il y a peut-être un problème légal. Il n’y a aucun problème technique.

Ha mais là on s’éloigne de la technique oui, les tiers de confiance doivent être établis par une autre entité, décorrélée le plus possible du site de p2p, et bien sûr l’entité de confiance doit pouvoir changer à chaque fichier (ie avant qu’elle ne soit repérée et infestée).

On en revient à la réduction des peers oui, et aux systèmes fermés type boards de warez, ce qui est un peu en contradiction avec le principe du p2p certes " />

Khalev

Le 26/06/2013 à 12h36

saf04 a écrit :

“Parmi ces chaines télévisées, certaines peuvent etre a accées protégé, par exemple des droits d’accés payants ou par la souscription à un abonnement payant ou non. Le contenu vidéo que le pair cherche a récupérer peut etre diffusé en streaming sur une de ces chaines télévisées.”

en fait c’est pour pas que ton fiston il streame le premier samedi du mois…

Perdu, c’est beaucoup plus direct que ça!

En variante, l’envoi au pair de faux blocs peut être conditionné à un profil utilisateur de l’utilisateur du terminal associé au pair. Ce profil comprend par exemple des informations telles que l’âge de l’utilisateur, de façon à ne pas permettre la visualisation par des enfants de programmes violents, par exemple.

Par contre là on a 0 explications sur l’identification des profils utilisateur (faut dire que le problème est un peu plus complexe que d’envoyer de la merde aléatoirement 2% du temps). Je rappelle que le logiciel a juste le rôle d’un pair qui reçoit une demande d’un bloc par une adresse IP random et qui envoie ou non un bloc correspondant.

Alors, soit le client Torrent enverrait un ID utilisateur avec ses demandes et chaque pair posséderait des infos personnelles sur chaque utilisateur de service de streaming P2P de France (c’est la CNIL qui va s’amuser à autoriser tous ces fichiers).

Soit c’est chaque service qui gère ça lui-même au niveau de son tracker : l’utilisateur renseigne l’âge associé à son compte, et le tracker décide, ou non, de donner les infos pour qu’il puisse récupérer le stream en question. Ce qui est tout de même un poil plus simple.

Ou encore plus débile : chaque pair avant d’envoyer son bloc demande au tracker s’il a le droit ou pas en se basant sur un ID utilisateur. Vous les voyez venir les possibilités de DDOS par amplification là?

saf04

Le 26/06/2013 à 12h37

Commentaire_supprime a écrit :

Car tout chiffrement nécessite forcément des cycles processeur et du temps de traitement et, dans le cadre de flux vidéo, faire ça en temps réel, c’est un poil tendu….

y’a aucun chiffrement dans l’histoire…

tmg se fait passer pour un utilisateur lamba. il t’envoie deux trois bon bout de fichier, puis un moisi.

si tu as de la chance, ton bout moisi est dans le buffer du logiciel et il est rejeté, ce qui te ralenti. sinon il est en affichage temps reel et tu vois le bout moisi avant qu’il ne soit vérifié.

y’a aucun cryptage, cassage de truc ou chais pas quoi.

edit: khalev, j’avais pas lu jusqu’au bout, mais c’est violent de clowneries en fait…

Naneday

Le 26/06/2013 à 12h42

Sabotage de donner, intrusion dans la vie privée de l’utilisateur, c’est beau la sécurité, enfin celle des ayant droits hein ..

canti

Le 26/06/2013 à 12h44

HarmattanBlow a écrit :

En quoi cela l’empêche t-il ? Qui définit ce qu’est un utilisateur légitime ? Comment distingues-tu un vrai utilisateur du réseau d’un faux utilisateur du réseau ?

Même si le site de streaming offre un mécanisme pour être le seul à fournir les identités légitimes, qu’est-ce qui empêche TMG de se faire passer aux yeux du site de streaming pour un utilisateur légitime ? Au pire le site de streaming pourrait stipuler dans ses termes du service que cette usage n’est pas toléré mais les sites ricains n’auront qu’à utiliser la même astuce que : profiter des barrières juridiques internationales.

Il y a peut-être un problème légal. Il n’y a aucun problème technique.

j’ai l’impression qu’on mélange un peu tout dans cette discution ….

>> si TMG est un utilisateur lambda, avec sa vraie adresse IP, et qu’il envoie de fausses données, il gènera le receveur, mais il pourra être identifié (pas forcement évident, mais faisable), et son IP bannie
   ==&gt;  pas un GROS problème pour TMG ils ont qu'a changé d'adresse, mais lourd tout de même, et c'est une solution qui réduira leurs force d'attaque    
>> si TMG usurpe l’IP d’un expéditeur normal, il peut réussir à déranger le receveur, et faire bannir l’expéditeur normal
 ==&gt; c'est un vrai problème pour le réseau, car si ils arrivent a faire bannir tout les gros partageurs, ils peuvent étouffer le réseau   


==&gt;  c'est la que le cryptage peut être intéressante : . Si tu établies une communication crypté avec un pair, ils ne peuvent pas usurper son identité pour le faire bannir a leurs places. Ca sera difficile a TMG d'intercépter les clés, car ils ne sont pas Man in the middle, mais en périphérie du réseau

psn00ps

Le 26/06/2013 à 12h44

tazvld a écrit :

Il me semble en effet que c’est quelque chose qui est prévu dans le protocole bittorrent en dévaluant les pairs qui envoient des paquets non valides. A ceci, une solution de type PeerBlock rendrait leur “solution” totalement inefficace. Ca sent surtout l’entubage d’administratifs car d’un point de vu technique, c’est inefficace (ou plus simplement de la poudre aux yeux pour justifier un nouveau contrat)

Ca pourrait servir à faire un DoS en envoyant de la m*de avec un spoof d’IP sur un pair valide.

doudawak

Le 26/06/2013 à 12h46

canti a écrit :

Apres, pour ce qui concerne la corrumption de ton fichier / stream, j’ai tendance a être plus sceptique, car le chunk que tu reçois en P2P a un hash, et quand tu reçois un paquet, tu le compares a ce hash attendu.

Ca voudrait dire qu’ils créent un bloc d’octet ayant le même hash, mais je pense que ce n’est pas évident avec les hash moderne…

C’est pas que c’est “pas évident”, c’est juste impossible…

Si le hash est identique (attention, je dis bien le hash, pas le fichier), quand il sera comparé au fichier, il y aura que 2 solutions :

le fichier correspond au hash, donc il n’a pas bougé d’un bit

le fichier est corrompu/empoisonné/whatever, on retélécharge le chunk

Dans le pire des cas, on va choper les chunk qui corrompus sur d’autres pairs et c’est réglé.

Le principe du p2p c’est justement d’aller choper les infos là où elles sont dispo ! TMG ou ton voisin, meme combat.

Ca sent bien le pipot quand meme ce brevet

psn00ps

Le 26/06/2013 à 12h47

Commentaire_supprime a écrit :

En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.

Cinq ans d’emprisonnement et 75 K€ d’amende potentiellement. Si TMG perturbe du streaming P2P légal avec un requérant sans pitié en face, ça va faire mal…

Contact entre les directions et shuuuut…

Communication du côté client : nous avons une légère perturbation, c’est pas nous c’est un stagiaire " />

A-D

Le 26/06/2013 à 12h48

Constance a écrit :

C’est toujours sympa de pourrir le réseau et générer du trafic pour de la merde.

C’est pas interdit ce genre de pratique ? En tout cas ça devrait…

C’est pas déjà le cas avec Youtube et cie " />

canti

Le 26/06/2013 à 13h09

ragoutoutou a écrit :

Et de quelle technologie de stream live on parle alors??? Parceque les sois-disant contremesures de TMG, ça n’est que du vent tant qu’il n’y a pas un protocole spécifique à empoisonner.

Et pour info, du stream live en p2p, c’est tout à fait possible à protéger si les blocs sont signés par l’émetteur: le client commence à lire et choppe la clef publique de l’émetteur dans les premiers blocs, et ensuite rejette tous les blocs ne correspondant pas à cette clef publique.

visiblement sopcast , mais je ne connais pas plus ( c’est cité commentaire #14)

j’ai l’impression de me répéter, je vais arreter de répondre rapidement, et attendre de bufferiser les questions pour répondre en bloc " />

tass_

Le 26/06/2013 à 13h10

Khalev a écrit :

Tu fais du 2 parmis 3.

Tu demandes 3 hash du même bloc à 3 clients différents et tu télécharges le bloc chez un de ceux qui à un hash que tu retrouves au moins 2 fois. Faut juste voir les délais que ça implique au niveau du calcul du hash. Après on a pas besoin non plus du plus gros hashage existant. Il ne conserve son intérêt que pendant 20 minutes grand max dans le cas d’un streaming live.

Ca serait pas mal ça comme solution en effet. Pas forcément 2 sur 3 mais oui récupérer les hash de toutes les sources qui proposent ce bloc et récupérer un de ceux dont le hash est majoritaire.

A moins d’avoir plus de sources de TMG que de “normales” je pense que ça peut marcher… Et ça ne devrait pas prendre tant de temps proc que ça…

Généralement c’est quand même le réseau qui bride le stream, et là on ne télécharge en plus que des hash, autant dire des quantités négligeables.. Reste le temps incompressible de l’échange avec les sources… mais rien n’empeche de pouvoir régler le nombre de sources dont on vérifie le hash.

psn00ps

Le 26/06/2013 à 13h10

canti a écrit :

non, tu parles d’identification de pirate, alors que ce n’est pas le sujet de la news (qui est plus la dégradation du P2P).

Le cryptage permet d’éviter le problème indiqué ici, car il empêche TMG de se faire passer pour ton interlocuteur légitime. leurs attaques se résume alors à du DoS (ils surcharges ta connection, et c’est cher à faire pour des millions de “pirates”)

HarmattanBlow a écrit :

Le cryptage

" />

canti

Le 26/06/2013 à 13h12

psn00ps a écrit :

" />

" />

Khalev

Le 26/06/2013 à 13h12

canti a écrit :

visiblement sopcast , mais je ne connais pas plus ( c’est cité commentaire #14)

j’ai l’impression de me répéter, je vais arreter de répondre rapidement, et attendre de bufferiser les questions pour répondre en bloc " />

Ces réseaux IPTV mettent en oeuvre leur propre logiciel, par exemple PPLive, SopCast,TV Ants, PPStream ou encore Stream Torrent. Ces réseaux utilisent par exemple la technologie Bittorent selon laquelle un contenu vidéo est divisé en blocs.

Page 3 du brevet. " />

canti

Le 26/06/2013 à 13h14

Khalev a écrit :

Page 3 du brevet. " />

tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. " />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT

saf04

Le 26/06/2013 à 13h16

canti a écrit :

tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. " />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT

tu peux aller lire le brevet au lieu de blablater ? tu verras bien ce que tmg explique.

doudawak

Le 26/06/2013 à 13h17

Commentaire_supprime a écrit :

Question bête : le chiffrement, comment est-ce qu’ils le cassent ?

C’est pas de dissimulation de protocole dont je parle, mais de transmissions de données chiffrées entre A et B. Et X, il fait comment son man-in-the-middle dans ce cas s’il n’a pas la clef de déchiffrement des données~? Et surtout, comment peut-il savoir que les données chiffrées qu’il voit passer sont du P2P, et non des ordres de vente boursiers, par exemple ?

Y a rien a casser !

Le principe du chiffrement en simplifié :

échange de clé PUBLIQUE en clair

échange de clé PRIVEE encryptée

communication chiffrée

Y a un article super bien expliqué chez le site du zéro :http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-d…

Khalev

Le 26/06/2013 à 13h18

canti a écrit :

tu noteras qu’ils en récupère la technologieBitTorent, pas qu’ils utilisent BitTorrent. " />

en particulier, ils n’utilisent pas de fichier .torrent, et ne vérifient pas le hash par rapport a une table de hash connu. Après c’est similaire a BT

C’est bien ce que je mettais en gras, mais ça va quand même à l’encontre de ce que tu disais.

Enfin c’est surtout que tu débattais sur un truc qui n’a pas d’intérêt dans le cas qui nous intéresse.

canti

Le 26/06/2013 à 13h20

saf04 a écrit :

tu peux aller lire le brevet au lieu de blablater ? tu verras bien ce que tmg explique.

j’ai pas le temps de lire des conneries dans un jargon juridique (après tout, c’est écrit par des avocat, par par des ingé/dev).

Mais si tu veux bien m’expliquer en 2 lignes comment tu fait pour générer un .torrent avec la liste des hash qui passeront sur un chaine de TV streamé, dans les 3 prochaines heures, je penses que tu pourras concurrencer Mme Soleil.

J’ai lut tout les commentaires de la news ( ce qui visiblement pas ton cas, vu que tu me reexplique que les .torrent contiennent les hash, alors que je l’explique dans les 1ers commentaire) alors si tu peux faire l’effort de m’expliquer, je te promet que je ferais l’effort de te lire

tass_

Le 26/06/2013 à 13h24

doudawak a écrit :

Y a rien a casser !

Le principe du chiffrement en simplifié :

échange de clé PUBLIQUE en clair

échange de clé PRIVEE encryptée

communication chiffrée

Y a un article super bien expliqué chez le site du zéro :http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-d…

Mais s’il y a cryptage alors TMG ne peut plus faire de spoofing d’IP et se faire passer pour un utilisateur connu du service, on en revient donc au ban d’une source qui envoie trop de données corrompues.

Donc si je résumes :

flux crypté => ban des sources après un nombre de blocs faux.

flux en clair => récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre.

Un faille à ce raisonnement ?

Khalev

Le 26/06/2013 à 13h25

doudawak a écrit :

Y a rien a casser !

Le principe du chiffrement en simplifié :

échange de clé PUBLIQUE en clair

échange de clé PRIVEE encryptée

communication chiffrée

Y a un article super bien expliqué chez le site du zéro :http://www.siteduzero.com/informatique/tutoriels/reprenez-le-controle-a-l-aide-d…

Et?

Cool TMG enverra ses faux blocs de façon sécurisé. Wouhou…

canti

Le 26/06/2013 à 13h25

Khalev a écrit :

Enfin c’est surtout que tu débattais sur un truc qui n’a pas d’intérêt dans le cas qui nous intéresse.

c’est quand meme pas ma faute si je me fait traiter de débile parceque je ne sais pas que les hash sont dans le fichier, alors que je l’explique au début, et que depuis 30 commentaires, les gens ont compris que dans la techno dont on parle il n’y a pas de .torrent et de liste de hash, parcequ’on ne peut pas prévoir ce qui passera au stream " />

ISFNoah

Le 26/06/2013 à 13h28

tass_ a écrit :

flux crypté => ban des sources après un nombre de blocs faux.

[…]

Un faille à ce raisonnement ?

Oui: tu confonds chiffrement et signature " />

saf04

Le 26/06/2013 à 13h30

canti a écrit :

j’ai pas le temps de lire des conneries dans un jargon juridique (après tout, c’est écrit par des avocat, par par des ingé/dev).

Mais si tu veux bien m’expliquer en 2 lignes comment tu fait pour générer un .torrent avec la liste des hash qui passeront sur un chaine de TV streamé, dans les 3 prochaines heures, je penses que tu pourras concurrencer Mme Soleil.

J’ai lut tout les commentaires de la news ( ce qui visiblement pas ton cas, vu que tu me reexplique que les .torrent contiennent les hash, alors que je l’explique dans les 1ers commentaire) alors si tu peux faire l’effort de m’expliquer, je te promet que je ferais l’effort de te lire

je ne dit pas que je sais comment le faire…

je te dis que c’est dont tmg parle dans son brevet, notamment page 4 pour evoquer la necessité d’envoyer beaucoup de blocs fiables avant pour rester un pair fiable dans les echanges.

canti

Le 26/06/2013 à 13h31

ISFNoah a écrit :

Oui: tu confonds chiffrement et signature " />

pas de signature sans chiffrement

ISFNoah a écrit :

“récupération des hash de plusieurs sources pour chaque bloc, et téléchargement du bloc dans une source qui a un hah commun au plus grand nombre”

=> Je pense pas que TMG s’amuserait à s’autogriller en indiquant spontanément le hash du paquet modifié au lieu du hash du paquet d’origine

si ils mettent le bon hash, tu verras que le paquet est mauvais une fois télechargé, et tu ne l’afficheras pas a l’utilisateur ( et par la même occasion, tu ne le partageras pas). c’est plus du DoS que de la corruption de flux video

Enyths

Le 26/06/2013 à 14h34

doudawak a écrit :

Excuses moi, tu m’a tué. C’est pas du pipot, c’est une connerie alors =)

La méthode n’est pas du pipeau car elle est envisageable.

C’est une grosse connerie car les protocoles s’ils sont vraiment encore sensibles à ce type d’attaque peuvent très bien être sécurisés. Et tout ça va nous coûter encore très cher dans nos chères finances d’état.

Alucard63

Le 26/06/2013 à 15h11

AntonyToku a écrit :

Pourquoi une pub m’agresse quand je clique sur ton lien?

Parce que t’as pas AdBlock?" />

127.0.0.1

Le 26/06/2013 à 15h38

Ainsi, TMG propose d’envoyer entre 100 et 500 Mo de contenu légitime avant d’empoisonner les flux

????

Bah, tant mieux alors…Ca fait au moins ¹⁰⁰⁄₅₀₀ Mo de contenu récupéré. Pour les autres blocs, bah ils viendront d’une autre source. Et, en bonus, la source TMG sera black listée pour la prochaine fois.

hadopisexy

Le 26/06/2013 à 15h51

Ils n’arrêtent pas a foutre leur merde et polluer le net ces gars de TMG et en plus on leurs paie avec votre argent! " />

N’oubliez pas a configurer correctement votre VPN " />

Onishin

Le 26/06/2013 à 19h24

Je donne 1 mois au developpeur pour ce mettre a niveau .

Et il vont commencer maintenant donc cela sera pret avant .

Simple de le torrent un clef prive .

Et tous les hash de block sont signe avec la clef sur torrent .

Si on recois un bloc valide mais donc la signature ne va pas . Hop poubelle et blacklist .

raysar

Le 27/06/2013 à 02h08

Ils innovent, c’est bien " />

2show7

Le 27/06/2013 à 07h18

" />désolé d’avoir occulté le premier mot du titre (aussi bien que l’article lui-même). L’article traitait bien que du P2P

La fatigue m’a égaré " />

" />

popolski

Le 27/06/2013 à 07h23

En droit français, l’atteinte à l’intégrité d’un système de traitement automatisé de l’information est un délit.

http://europa.eu/legislation_summaries/information_society/internet/l33193_fr.ht…

http://www.droit24.fr/a/comment-sont-sanctionnées-les-infractions-informati…

Laskov

Le 28/06/2013 à 03h42

et donc si on a la malheur de streamer une video crée par nous meme qui a le meme hash qu’unre video illicite on fait comment ? " />

fred42 Abonné

Le 28/06/2013 à 07h52

Laskov a écrit :

et donc si on a la malheur de streamer une video crée par nous meme qui a le meme hash qu’unre video illicite on fait comment ? " />

Si tu arrives à cela, je te conseille le loto ou l’euromillion " />

Catégories

Nous Suivre

À propos

P2P : Trident Media Guard veut polluer le streaming de flux vidéo illicites

Le flux enchanté

Commentaires (141)