|
|
|
Un lobbyiste suédois avoue : la pédophilie est leur cheval de Troie
Sujet ouvert par
artconspiracy
- Dernière réponse le 29 novembre 2010 à 14h05
Ils auraient trouvées autre chose !
Ils veulent filtrer, ils filtreront ce qui ne sera pas protégé. A moins d interdire les VPN. 
ils vont faire quoi ... filtré les ip des VPN "publique" ? et après , rien n'empeche quelqu'un de louer un serveur offshore pour le faire
 . jvoudrais bien les voir essayer de m'interdir mon acces a mon serveur dédié tient ...
cooperman, le 29/04/2010 - 13:58 Pas vraiment possible ca, a moins de casser pas mal de choses. Les VPN servent à tous un tas de professionnels. Difficile d'empêcher aussi le cryptage. La France l'a déjà fait il y a pas mal d'années, le bilan a été plutôt lourd sur l'économie parce que ca aussi des boites s'en servent. D'autres pays comme les US, qui n'avaient à l'époque pas voté de lois aussi restrictives que la France en a tiré son épingle du jeux au niveau économique. Globalement, on ne peut pas faire n'importe quoi sur quelque chose qui impacte autant que le net sans en subir de conséquences (ce qui est fait en ce moment...) 
identifiant, le 29/04/2010 - 16:30 :mouarf: Interdire iPredator en France ne revient pas à interdire 'tous les VPN'. Tant qu'aux cryptage, les entreprises qui veulent l'utiliser doivent faire une déclaration pour obtenir une autorisation. Rien n'empêche de pousser la logique plus loin, rien n'empêche de punir d'amende lourde l'utilisation de Tor ou Freenet. Bref : ils font ce qu'ils veulent, ils sont les plus forts. C'est pas avec des bidouillages techniques qu'on gagnera la partie. 
ptitecoquine, le 02/05/2010 - 02:24 Il ne suffit pas de décréter une loi. Il faut aussi qu'elle soit applicable. Or, est-il facile par exemple pour un FAI de détecter un flux tor ? Le flux est crypté (il l'est même triplement, mais ça le FAI ne le sait pas), et le FAI voit une connexion à une certaine IP (qui se trouve être un Tor bridge). Mais le FAI sait-il que l'IP en question est, justement, un point d'entrée à Tor ? Les exits nodes sont publics, mais les entry-nodes ? Quoi qu'il en soit, dans le scénario que tu décris, il pourrait alors s'envisager, dans le pire des cas, de non seulement crypter, mais aussi steganographier les flux, pour qu'ils ressemblent à quelque chose de non crypté (encore qu'il me semble qu'avec Freenet et Gnunet ce soit "presque le cas", les flux Gnunet par ex ressemblant il me semble à de l'email). C'est les FAI qui vont être content, à qui Albanel avait fait miroiter qu'Hadopi leur ferait gagner de la bande passante. Pour les vpn, s'ils ne sont pas tous interdits, il restera peut-être possible de se connecter à ipredator à travers un vpn autorisé ? Ou peut-être y aurait-il assez d'utilisateurs offshore qui accepteraient de servir de "vpn bridge" pour permettre l'accès au vpn à ceux à qui cet accès est interdit. Mais ça limiterait l'utilité des vpn. Autant passer à Gnunet/Freenet en mode stéganographique. On peut aussi penser à des réseaux citoyens à base de wimax. Mais il est clair qu'il ne faut sûrement pas se contenter d'agir qu'au niveau technique, je suis bien d'accord. [message édité par jiang le 02/05/2010 à 06:15
]
jiang, le 02/05/2010 - 05:56 What what ? Les flux Thor ne sont pas cryptés. Ensuite, triplement crypté ? C'est quoi un triple cryptage ? Ça ne veux rien dire. Mais bon, comme thor ne crypte pas, ce n'est aps bien grave.
deadalnix, le 02/05/2010 - 15:07 Thor ne crypte peut-être pas, mais Tor oui. Et le cryptage est triple au sens suivant:
(Compromising Tor anonymity exploiting P2p information leakage, Inria). Donc, le FAI, qui est entre le client et le noeud 1, il voit quoi au juste ? Un flux crypté ou totalement clair ? [message édité par jiang le 02/05/2010 à 16:12
]
Le flux est crypté entre toi et le dernier peer. Après, c'est tout en clair.
Et triplement crypter, ça n'a aucun intérêt d'un point de vue crypto/sécurité.
deadalnix, le 02/05/2010 - 17:28 Ok, et j'ai jamais dit le contraire. Simplement, il était question de ce qu'est capable de voir et de comprendre le FAI du client qui voit passer un flux entre ce client et l'entry node Tor. Et je maintiens que ce flux là est (triplement) crypté. Maintenant, bien que crypté, y-a-t-il une marque permettant ce savoir qu'il s'agit spécifiquement d'un flux Tor ? Ce point là je l'ignore (ou je l'ai complètement oublié si jamais je l'ai sû un jour). Mais si rien de spécifique n'identifie un flux Tor d'un autre flux crypté illisible, je ne vois pas comment le Fai pourrait filtrer ou bloquer les flux Tor. A moins d'interdire systématiquement tout flux crypté quel qu'il soit. La "sécurisation" si chère à Hadopi serait alors en bonne voie... Et les plus obstinés en viendraient de toute façon à la stéganopraphie pour masquer du crypté dans du non crypté.
Ca, il faut que tu l'expliques aux concepteurs et développeurs de Tor, qui depuis toutes ses années et sans s'en rendre compte persistent à implémenter un truc qui sert à rien.
Je te conseille cette lecture :
ftp://ftp.inf.ethz.c...s/MauMas93a.pdf En gros, il est dit que quand tu utilises des chiffrement en cascade (comme le fait tor), la seule garantie cryptographique que l'on ai est que le chiffrement est au moins aussi sur que le premier. En gros, chiffres trois fois peut ne pas être plus sur que de chiffrer une fois. Si les chiffrement sont commutatifs (par exemple avec un cypher basé sur un xor) alors le chiffrement à la solidité du chiffrement le plus sur. De plus, il était possible d'établir le chiffrement directement avec le dernier peer, via l'utilisation de Diffie Hellman : http://fr.wikipedia...._Diffie-Hellman 
deadalnix, le 02/05/2010 - 17:28 En fait le but du chiffrage multiple (principe de l'oignon) c'est de cacher aux différents noeuds le chemin que doit suivre le message (c'est à dire le routage). Chaque noeud recevant un "oignon" chiffré commence par le décrypter pour savoir à quel autre noeud il doit transmettre l'oignon pelé auquel il vient de retirer une couche de chiffrage/routage. En espérant avoir été clair. deadalnix, le 02/05/2010 - 22:37 Très intéressant, merci pour le lien.
On obtient plus de sécurité si rien n'est connu concernant le texte clair.
Mais ça peut aussi l'être, comme par exemple avec le 3DES (ou se succèdent les 3 phases : chiffrage, déchiffrage, chiffrage; chacune employant une clé DES différente)
A condition que les chiffrages soient indépendants : par exemple dans le cas d'un chiffrage de flux RC4 il faut que les clés soient différentes, sinon on retrouve le message en clair, je sais c'est une évidence
deadalnix, le 02/05/2010 - 22:37 Merci pour le lien.
Moi je dirai plutôt à partir de ce qui précède qu'en chiffrant 3 fois, on est sûr d'avoir un chiffrement au moins aussi solide qu'en chiffrant une fois.
Je n'en disconviens pas, mais il n'empêche que Tor utilise un triple chiffrement, et que ce triple chiffrement sert à quelque chose, du point de vue de de la sécurité, de la confidentialité et de l'anonymat. L'intérêt du chiffrage en oignon, il est qu'aucun noeud du circuit ne sait quel est l'exit node (choisi initialement par le client, lors de la définition du circuit qu'il va utiliser pour envoyer son message), et qu'aucun noeud du circuit ne sait non plus qui est l'expéditeur originel du message. Imagine en effet que tu te contentes de: 1) choisir un circuit de 3 noeuds (n1 entrée, n2 mileu,, n3 sortie) 2) crypter ton message par exemple avec la clef publique du noeud 3. Tu serais alors obligé d'envoyer au noeud 1 un message contenant * la version cryptée (par la clef publique du noeud 3) de ton message m, que je vais appeler (m)_3 * l'adresse a2 en clair de n2 (car il faut bien que n1 sache à qui transmettre ce que tu lui envoies) * l'adresse a3 de n3 (pour que lorsque n2 reçoit ton paquet via n1, il sache que c'est à n3 qu'il doit le transmettre). Donc en fait tu transmets en gros à n1 le contenu suivant: (m)_3|a3a|a2 (| signifiant la concaténation, disons). Ce faisant, n1 connait donc le destinataire n3 (à l'intérieur du réseau Tor) de ce que tu lui expédies; et il peut deviner aussi qu'il joue pour toi le rôle de noeud n1, puisqu'à ton message crypté (m)_3 est ajouté 2 adresses, c'est à dire que n1 sait que tu ne fais pas que transmettre le contenu que tu lui envoies, mais que tu en es l'auteur. Et le noeud n2 sait que le noeud n1 d'où il reçoit le message n'est pas l'initiateur du message, et que le noeud à qui il doit transmettre est le noeud de sortie que tu as choisi. Le noeud n2 sait donc à qui il doit s'adresser pour connaître le contenu de ce qui passe par lui (à n3 dont il connaît l'adresse), et il sait à qui il doit s'adresser pour savoir qui estr l'auteur de ce message (il lui suffit de s'adresser à n1, dont il connait l'adresse puisque n1 a communiqué avec lui). Si n2 "a les moyens de faire parler" n1 et n3, le contenu de ton message est révélé, ainsi que ton identité.  Et si n2 est "neutre" mais que par hasard n1 et n3 sont des pirates qui collaborent, peuvent également être découvertes et ton identité (connue de n1) et le contenu de ton message (connu de n3 qui seul peut décrypter ce que tu fais passer dans le réseau).  Pas terrible donc point de vue sécurité.....  A la limite, dans un tel protocole, le plus sûr pour toi, la configuration pour laquelle tu dois prier, c'est quand n1 appartient aux services secrets US, n2 aux russes, et n3 aux chinois.  Au contraire, dans le protocole Tor, après avoir défini ton circuit n1 n2 n3, tu fais en gros ceci ceci: 1) Tu crypte ton message m avec une clef publique de n3, ce qui donne (m)_3 2) Tu y adjoins l'adresse de n3, que je vais appeler a3, ce qui donne (m)_3|a3 3) Tu cryptes tout ça avec la clef de n2, ce qui donne ((m)_3|a3)_2 4) Tu y adjoins l'adresse de n2, appelée a2, ce qui donne ((m)_3|a3)_2|a2 5) tu cryptes le tout avec la clef publique de n1 ce qui donne (((m)_3|a3)_2|a2)_1 6) tu concatènes l'adresse a1 de n1 pour faire joli, ce qui donne (((m)_3|a3)_2|a2)_1|a1, et tu expédies le tout à n1. Lorsque n1 reçoit le bazar, il est incapable de savoir que c'est toi qui es l'auteur du message, ou si tu n'est qu'un noeud n1 dans le circuit choisi par un autre et dont il serait lui le noeud n2. La seule chose qu'il sait, c'est qu'il n'est pas le noeud de sortie n3, et qu'il doit envoyer le paquet à n2, dont il ne sait pas s'il est un noeud intermédiaire ou le noeud de sortie. n1 débarrasse donc (((m)_3|a3)_2|a2)_1|a1 de son adresse à lui, décrypte (((m)_3|a3)_2|a2)_1 avec sa clef privée, et envoie (m)_3|a3)_2|a2 à n2. Lequel n2 ne sait pas si n1 est l'auteur du message qu'il reçoit, ou un simple proxy dans le circuit. Et il ne sait pas si n3 à qui il doit envoyer (m)_3|a3 joue dans ton circuit le rôle d'exit node, ou s'il n'est qu'un noeud intermédiaire du circuit. Si par exemple n1 et n3 collaborent, ils ne pourront rien prouver, car le message (m)_3|a3 reçu par n3 (et qu'il a décrypté), n'a rien a voir avec le message (((m)_3|a3)_2|a2)_1|a1 que n1 a reçu de toi (et dont il n'est même pas sûr que tu sois l'auteur). Quant à n2, il ne sait pas à qui il faut s'adresser pour avoir révélation du contenu du message, et il ne sait pas non plus à qui il faut s'adresser pour en connaître son expéditeur originel. Donc, le triple chiffrement en oignon augmente considérablement la sécurité du système. 
jiang, le 03/05/2010 - 01:08 Tu as sauté la case Diffie Hellman  Ça serait plus simple pour tout le monde si un Diffie Hellman se faisait entre le dernier peer et la source.
deadalnix, le 03/05/2010 - 04:17 Non ce ne serait pas une bonne idée, parce que la mise en oeuvre du protocole Diffie Hellman impose une communication entre la source et le dernier peer. Il deviendrait alors possible d'identifier le peer de sortie avant même de transmettre les données à faire acheminer. De plus mettre en place un simple cryptage (en générant une clé secrète à partir de Diffie-Hellman) entre la source et le dernier peer ne résout pas le problème de la confidentialité du routage au sein du réseau Tor (un problème solutionné par le chiffrage multiple en oignon).
Croux, le 03/05/2010 - 19:17 C'est parceque tu penses trop routage par paquet plutôt que par circuit La source envoie un paquet à un peer au pif : ouverture de connection. Le peer à deux choix : faire suivre la demande ou prendre en charge la demande, avec disont un facteur de branchement de 2/3. Ainsi, les peers ne savent pas s'ils parlent à la source ou non, ni qui est le n½ud de sortie. C'est même plus fort que la solutiona ctuelle car la source en connais pas son peer de sortie, ni même son routage au sein de tor. Tous les champs doivent être remplis. Tous les champs doivent être remplis. Tous les champs doivent être remplis. |
Sujets liés :
LES + RECHERCHÉS
A VOIR AUSSI
Télécharger
total video converter,
online tv adult,
ultrasurf,
voissa anonymo,
windows 7 gratuit,
antivirus avast,
passion,
redtube video downloader,
Accès rapide :
Encoder ou convertir |
Personnalisation |
Diagnostic |
eMule (et mods eMule) |
Photo numérique |
Outils Réseau |
Codecs et plugins |
|
”Child pornography is great,” the speaker at the podium declared enthusiastically. ”It is great because politicians understand child pornography. By playing that card, we can get them to act, and start blocking sites. And once they have done that, we can get them to start blocking file sharing sites”.
Source : http://christianengs...-porn-strategy/