Olivier a écrit 889 commentaires

Le reste est fait en P2P normal. Me trompé-je?

Dans ce cas-là, adieu l'anonimisation : Si, disons, Mr Hadopi et ses copains mettent la main sur un contenu qui est recherché (par exemple, et étant le premier seeder...), ils verraient alors toutes les connexions de contenus (ie : films, musiques, softs, ebook, et j'en passe) qui partent de chez eux, et qui vont directement chez le leecher.

D'après la vidéo, ce que j'ai compris c'est qu'à la fois les flux de recherche et ceux de contenus, passent par le mécanisme d'amis. Et c'est d'ailleurs, avec le chiffrement d'un bout à l'autre des flux, le seul moyen de garantir réellement l'anonymat.

Aucune idée, je ne l'ai jamais testé.

Mais comme souvent pour les réseaux P2P, la vitesse est en grande partie dépendante du nombre d'utilisateurs, donc de sa notoriété.

Il me semble que le principe d'anonymisation est similaire à celui de ANts :
http://antsp2p.sourceforge.net/
http://en.wikipedia.org/wiki/ANts_P2P

Mais avec les fonctionnalité de visualisation du contenu en moins.

Je connais plusieurs niveaux dans le tatouages :
- tatouage de disque dur :
Le constructeur planque, généralement au début de disque, un tatouage que Windows va lire à démarrage, et qui correspond à un clé fournit par Windows au constructeur. Si la clé et le tatouagee ne correspondent pas (ou que le tatouage n'existe pas), c'est que le Windows a été installé sur une autre machine que celle du constructeur.
Le but de la manoeuvre est d'éviter que le DVD de restauration du constructeur xxxx soit utilisé sur la machine du constructeur yyyy, voir d'une machine assemblée
Personnellement, je me suis amusé à me faire une petite "collection" de MBR et de "piste 0" de disque, contenant ce type de tatouage

- tatouage du BIOS:
Au lieu de mettre le tatouage sur le disque dur, celui-ci est mis dans le BIOS (il a plein de zones inutilisées). Puis, c'est le même principe que plus haut : Windows recherche le tatouage (dans le BIOS), si il n'existe pas, ou qu'il ne correspond pas à la clé, Windows refuse de démarrer.
A mon boulot, c'est une technique que nous utilisons pour les PC qui sont fournit dans des machines-outils

- tatouage du BIOS avec verrouillage du boot :
c'est ce qui a été décrit dans un autre post.
Je n'ai pas eu l'occasion de me retrouver face à une telle situation, mais j'ai plusieurs fois lu ce genre de choses venant de "gros" constructeurs.
Evidement, ce type de comportement est inadmissible de la part du constructeur, et le PC mérite d'être retourné au fabriquant, pour vice de fabrication !

- enfin, il existe probablement d'autres techniques de tatouage

Ta dernière proposition ne te dispense pas du coût des licences Win$ et M$Office.

Pour ce qui est du Windows, celui-ci a probablement été livré avec le portable neuf, avec très probablement une licence OEM.

Techniquement parlant, cette licence oblige l'utilisateur à n'utiliser ce Windows que sur le portable en question. Mais, à priori, rien n'empêche que le Windows soit virtualisé. Reste à le faire fonctionner malgré les, probables, mesures de tatouage du BIOS...

Pour ce qui est du MS Office, si la boîte de son épouse est assez grosse, il est possible qu'elle ait des accords avec MS pour pouvoir installer le pack Office sur les machines perso de ses employés.

Mais bon, cela nous éloigne assez du contenu libre de ce site... :)

où vais-je pouvoir aller chercher mes adresses ? Directement à la racine ?

Oui : rien ne t'empêche d'interroger les DNS primaires. Mais si tout le monde le fait, ils risquent d'être très surchargés.

Sur une Debian, le paquet "bind9" te fournit une liste de DNS primaires : /etc/bind/db.root

Tu peux un peu limiter les accès, en installant ton propre serveur DNS dans ton réseau, afin qu'il agisse comme un "cache" DNS (c'est d'ailleurs en parti ce que font les DNS de ton FAI).

Enfin, si tu veux aller régulièrement sur un site "blacklist" par ton DNS, je vois 2 possibilitées:
- si le site est assez gros, et à sa propre plage d'IP, tu n'as qu'à rentrer son coupe nom/ip dans ton /etc/hosts
- sinon, tu :
1) installe un serveur DNS, et tu le configures pour qu'il soit serveur d'autorité pour le domaine qui est blacklisté. Bien sûr, le serveur DNS ne devra pas être accessible depuis l'extérieur de ton réseau
2) et pour la la résolution du nom, tu colles l'adresse IP fixe du site, ou une résolution de nom via un DNS racine
Ainsi, pour les requêtes DNS "classiques", tu pourras passer par le DNS de ton FAI. Mais pour l'accès à ce site en particulier, tu switcheras sur une autre résolution de nom.

Sur une Debian / Ubuntu, le ".config" qui a été utilisé pour compilé le noyau se trouve dans /boot/config* . Exemple : /boot/config-2.6.32-5-686-bigmem

Je ne sais pas si les autres distributions le font aussi.

Maintenant, a chaque fois que je redémarre, il faut que je reconfigure mes DNS...

Le problème n'a rien à voir avec GNOME, mais avec "NetworkManager", un démon qui gère les connexions réseaux. Dans les distributions, il discute généralement à une appli de type "barre de tache" qui permet de voir en temps réel le statut de la connexion : câble débranché, basculement sur le wifi, voir configuration du wifi, etc...

Si tu utilises une adresse IP fixe, il te suffit de désactiver le support de network-manager, en renseignant à la main ta configuration réseau dans /etc/netwkork/interfaces (bref, la bonne vielle méthode) :

# Reseau local
auto eth0
iface eth0 inet static
address 192.168.0.x
netmask 255.255.255.0
network 192.168.0.x
broadcast 192.168.0.255
# dns-* options are implemented by the resolvconf package, if installed
dns-search x.x

NetworkManager va tout simplement gérer les autres interfaces qui NE se trouvent PAS déclarées dans /etc/netwkork/interfaces


Sinon, si tu as un client DHCP, mais que tu veux forcer l'utilisation d'un DNS bien particulier, il y a les options qui-vont-bien dans le /etc/dhcp/dhclient.conf :

# (2009/07/25): Force l'utilisation de "toto.net" comme nom de domain
prepend domain-name "toto.net";

# (2008/05/14): Place "127.0.0.1" en tete de liste des serveurs DNS
prepend domain-name-servers 127.0.0.1;

# (2008/05/14): N'utilise que "127.0.0.1" comme serveurs DNS
supersede domain-name-servers 127.0.0.1;

Ces options existent depuis, pfffff longtemps. Voir "man dhclient.conf" pour les détails.

D'autant que les sites en questions peuvent très bien mette un message sur leur première page :

Vous avez des problèmes pour vous connecter à ce site ? Essayez les techniques ci-dessous:
- xxxxxxx (changement de DNS)
- yyyyyyy (utilisation de l'adresse IP)
- zzzzzz (passage par un proxy)
- etc...


L'information, une fois su, fera rapidement boule de neige après des utilisateurs....

Pour information, lorsque une machine Ubuntu démarre, elle connecte son client NTP (Network Time Sychronisation) à ntp.ubuntu.com.

C'est juste pour mettre la machine à l'heure.

D'un autre coté, les gens de Canonical peuvent, en analysant les connexions à ce serveur, avoir une idée du nombre de machines Ubuntu dans la nature. Et ils ont aussi l'adresse IP de ces machines-là (ou au moins, celle du dernier proxy/routeur qu'elles utilisent)

Pour Debian, c'est la même chose :
- lors de l'installation en "net install", dès que le client DHCP est lancé, la première chose qui est faite est une mise à l'heure la machine, sur debian.pool.ntp.org
- lorsque tu installes le paquet NTP (je ne me souviens plus de si il est installé par défaut), le serveur de temps est debian.pool.ntp.org

Et (encore) pour information, les machines sous Windows se synchronisent sur time.windows.com

C'est probablement une Mandriva, du fait de la dénomination en année (2010 / 2010.1)

Bravo en tout cas pour tout ce travail, et merci pour cet intéressant article.

Comment reconstruit-on la config ?

A mon avis : Backup du /etc/udev/

Puis, ré-installation de udev, via : "apt-get install udev" ou "aptitude install udev"

J'aime bien dissocier l'archivage de la compression.

Je ne suis que moyennement d'accord avec l'intérêt de ceci, tout spécialement pour deux cas :
- afficher la liste des fichiers de l'archive.
+Dans le cas d'un archivage suivit d'une compression, tu ne peux pas récupérer la liste des fichiers, sans parcours intégral de tout le fichier. Si tu as 20 go d'archive en .tar.gz sur un disque en USB 1.0, cela prendra du temps pour récupérer la liste.
+ Par contre, dans le cas d'un archivage avec compression intégrée (zip, rar, etc....), le soft de décompression peut faire des "sauts" dans l'archive, afin de retrouver la liste des fichiers. Cela limite la quantité de données lues dans le fichier, donc le résultat arrivera plus vite

- résistance à la corruption :
+ Si tu prends un .tar.gz, et que tu le corromps (écriture aléatoire de données dans le fichier), l'extraction bloquera dès la première erreur trouvée
+ D'autres formats qui lient archivage et compression (arj par exemple) supportent largement mieux la corruption. Les données compressées situées dans la zone corrompu seront certes illisbles. Par contre, les autres, et tout spécialement ceux situés après la zone corrompu, seront extractable. On perdra donc quelque chose, mais pas tout...

Bon l'inconvénient c'est qu'à priori je ne pourrai pas utiliser de SSL sur un serveur chez moi car dans ce cas il faudrait rediriger ce port 443 et donc il y aurait un conflit.

Personnellement, j'utilise SSLH ( http://www.rutschle.net/tech/sslh.shtml ), pour contourner le problème.

il s'agit d'un "wrapper", qui permet de switcher une connexion entrante sur un port (typiquement TCP/443), afin de la rediriger soit vers un serveur HTTPS (SSL), soit vers un serveur SSH.

C'est du C, donc cela doit pouvoir se compiler, et s'exécuter directement sur on WRT. Après, il ne te reste qu'à le configurer, pour diriger les flux SSL et SSH vers les bons serveurs.

On aura l'air bien cons quand le réseau sera une resucée d'un minitel.

Parce que tu crois réellement que les instances dirigeantes ont besoin des "vilains téléchargeurs" pour vouloir mettre au pas Internet ?

Il y a 15 ans Internet ne faisait pas peur aux dirigeants (de tout pays), parce que cela ne touchait qu'une petite frange de la population.

Maintenant, tout le monde peut avoir accès à Internet (y compris via des lieus publics, et pour des coûts parfois très faibles), et tout le monde peut y poster ou y lire n'importe quoi. Y compris et surtout des informations qui dérangent les gouvernements.

Les lois HADOPI et LOPPSI sont là, non pas pour contenir le "vilain téléchargement pirate", mais pour brider l'Internet que nous connaissons, afin de le museler.

HADOPI veut tous nous voir installer son "logiciel de sécurisation", qui pourra évoluer très très vite en un "mouchard" beaucoup plus puissant, aidant par la même la LOPPSI, avec son soft de prise en main à distance.

La Chine muselle son Internet. Les pays plus "démocratiques" rêvent de faire la même chose, mais de manière moins "choquante" et moins visible. La lutte contre le téléchargement illicte lui en donne la possibilité.

Oui, c'est sans doute abusif comme comportement.

Mais face à un tribunal, je pense que cela risque d'être dur de prouver que le "briquage" soit volontaire de la part du constructeur, et que ce n'est pas le fait d'un firmware jaibraké qui soit vérolé.

Cela risque de partir en procès d'un an ou plus, comme pour les premiers cas d'OS Windows pré-installé non remboursé. Et encore, dans ce cas précis, la licence de MS indique clairement que l'on peut se faire rembourser le Windows.

Bref, je souhaite bon courage pour les personne qui voudront acheter un produit de ce type, et qui verrons leur téléphone se transformer en brique...:=(

Et pour l'alerte bouchon, tu fais comment ?

J'écoute "autoroute info"

Ou je vais sur http://www.bison-fute.equipement.gouv.fr/diri/listeflashs.do avant de partir

La réponse est dans le journal : La puce bloquera le téléphone, mais seul Motorola aura la possibilité de le débloquer à nouveau. Par exemple via un équipement hardware qui se connectera à un endroit particulier du téléphone.

Ainsi, le téléphone ne sera pas déduit, mais "simplement" à renvoyer au SAV, qui le "réparera", évidement à prix d'or. Et en y remettant bien sûr la flash d'origine...

Pas de destruction physique, donc...

Quand au problème de licence, cette histoire me rappelle celle assez récente de la Playstation, dont un upgrade de BIOS empêchait l'utilisation de Linux (or cette machine avait conçu et vendu à l'origine comme pouvait faire fonctionner un Linux). Il était clairement indiqué dans le contrat de licence que le constructeur pouvait ainsi supprimer une fonctionnalité de la machine. Mais, aux EU en tout cas, cela n'a pas tenu contre un juge, car cela a été considéré comme une clause abusive.

Pareil, je ne vois pas l'intérêt de ces smartphones.

J'ai Internet au boulot et à la maison, cela suffit.

Lorsque je ne suis pas ces deux endroits, je n'éprouve pas le besoin d'envoyer / recevoir des mails ou de me connecter au réseau pour savoir, le temps qu'il fait, ou pour avoir la dernière information de mes flux RSS

Pour les fonctions de localisation - recherche de route, j'ai un GPS qui ne discute avec personne, et cela me va très bien. Certes, je n'ai pas l'alerte radar en temps-réel, mais je m'en moque, car je respecte les limitations de vitesse.

Mon boulot peut me contacter 24h/24 et 7j/7, mais pour cela il faut que l'on fasse (l'énorme) effort de m'appeler "en vocal", plutôt que de me laisser un mail plus ou moins impersonnel. Ce qui me permet de gauger de l'importance réel du problème, et d'intervenir si cela est réellement utile.

Bref, ne pas être connecté en permanence, cela a du bon... ;)

j'ai beaucoup de mal à comprendre ce qu'y gagne le constructeur. vraiment, j'ai beau chercher, je ne vois pas.

Il y a, à mon avis, plusieurs possibilités :
- réduire le nombre de retour en SAV pour les personnes qui auraient un problème avec leur téléphone, après utilisation d'un téléphone qui aurait été flashé. Le constructeur peut estimer qu'une "mauvaise" rom peut endommager le matériel, ou apporter des dysfonctionnement. Exemple : Une rom qui consomme tellement de CPU pour faire de l'affichage graphique, que cela affecte la qualité de la téléphonie. Dans ce cas, les utilisateurs auraient une mauvaise perception de la qualité du téléphone.

- cacher le fait qu'une partie non-négligeable des taches sont effectuées par le soft, plutôt que par le hardware. J'ai en tête notamment ce qu'il se passe avec les imprimantes, et spécialement les Canon, où le soft fait tout le boulot. Ce qui permet d'avoir un hardware moins performant, et moins cher.

- bien sûr, les rom officielles peuvent avoir toutes sortes de fonctionnalités cachées et peut avouable, comme par exemple le fait de "tracer" les utilisateurs, en utilisant le GPS intégré. Il y a quelques mois, on avait découvert qu'un téléphone faisait ce type de choses, et envoyait régulièrement à son constructeur, des rapports sur l'usage fait du téléphone. Une rom non-officielle permettrait de désactiver ce genre de "flicage".

- évidement, la ligne au-dessus va de paire à l'usage de la publicité ciblée, comme le fait iPhone avec son "iAds", et c'est sans doute le rêve de tout commercial de la publicité : Vendre des informations excessivement précises de clients (plus elles sont précises, plus les informations se vendent chères), sur l'activité d'une personne

- garantir à leurs clients directs (pas les utilisateurs, mais les fournisseurs de téléphonie, comme Orange, Free, SFR, etc...), que l'usage du téléphone ne sera pas contourné. Je pense par exemple à [mettre ici le nom d'un FAI que vous n'appréciez pas] qui refuse que les téléphones soient utilisés comme "modem", afin de connecter un ordinateur dessus, pour surfer sur le net. Ou du moins, pas sans un substantiel surcoût de l'abonnement

- j'imagine qu'il y a sans doute beaucoup d'autres raisons, toutes très discutables, qui font que les fabricants veulent que l'on garde leur rom officiel.

Personnellement, je préfère prendre mes distances avec ce type de produit, qui serait à même de me surveiller dans tout mes déplacements.

Oui, je confirme : SSL et SSH ne réagissent pas de la même manière, et les équipement réseaux qui se trouvent entre serveur et client, typiquement un proxy transparent, peuvent voir la différence.

Personnellement, je suis passé par SSLH ( http://www.rutschle.net/tech/sslh.shtml ), pour contourner le problème.

il s'agit d'un "wrapper", qui permet de switcher une connexion entrante sur un port (typiquement TCP/443), afin de la rediriger soit vers un serveur HTTPS (SSL), soit vers un serveur SSH.

Coté SSH, il suffit de taper la commande : ssh -oPort=443 user@host

Ce n'est pas complètement faux...

Mais ce mot de passe (utilisé pour le partage de fichier) permet aussi d'avoir un login sur la machine Windows, donc il serait préférable d'éviter de corrompre 2 machines (Windows + Linux) uniquement en accédant en temps que root à une seul (Linux).

OK, merci de tes réponses.

Mes informations étaient de toute évidences erronées !

C'est la première chose à laquelle j'ai pensé.

Mais le contenu du fichier reste visible de la part de son propriétaire, et c'est quand même un mot de passe.

Je pourrai sécuriser un peu plus les choses en ne laissant qu'au root un accès en lecture au fichier, et en utilisant un sudo pour faire le montage. Mais le mot de passe restera toujours en clair.... :=(