Matthieu a écrit 2124 commentaires

Ben oui, quand je me ballade avec mon 770 pour checker des mails, j'aime bien trouver des réseaux ouverts.
C'est clair c'est pratique. Un peu comme moi quand je me ballade en ville. J'aime bien trouver une voiture ouverte avec les clés dessus pour rentrer chez moi, au lieu de prendre le bus.

En fait, je crois que si les Wifi sont si peu sécurisés c'est tout simplement parce que le mal que ça peut engendrer est complètement minime par rapport à la complexité de la sécurisation.
Cela peut aussi indiquer que la solution n'est pas assez mature. Tu accepterais d'acheter une maison dans aucune porte n'est pourvue de serrure permettant ainsi à tout à chacun de se servir chez toi ? Moi non. Tu aurais accepté que les impôts ait mis en ligne un site permettant la déclaration en ligne sans sécurité, permettant ainsi à tout le monde de venir voir tes infos ? Moi non, et ils ne l'ont pas fait heureusement.

C'est vrai quoi.. Si je bouffe 100Ko de ton quota pour aller voir mes mails, ça te pose réellement un problème ?
Le problème n'est pas le débit que tu vas utiliser. Mais plutôt les risques juridiques que cela implique. Imagines que tu sois une personne mal-intentionnée qui ait envie de modifier son salaire dans la base de données de ta boîte, ou modifier le montant de tes impôts dans la base des impôts ! Comment je fais lorsque la police me demandera des comptes ?
-> on ne se protège pas contre les personnes bien-intentionnées, mais contre les risques encourus, même s'ils sont stastistiquement faible (le risque de te faire voler ta voiture est très faible, mais ça peut arriver).

Un ordinateur est un outil, c'est fait pour aider, ou être plus productif! Pour la plupart des gens, le wifi permet aux gens de passage de se connecter facilement, qu'ils soient sous windows,linux/macos/JeanKevinOs!

C'est exactement la phrase qui hérisse mes poils (et sûrement ceux qui sont sensibilisé à la sécurité informatique) : mettre en premier plein l'usuabilité de l'informatique, avant la sécurité. Et c'est bien uniquement dans ce domaine que cela existe: on met des serrures à nos portes, on ferme à clé nos voitures... mais pour l'informatique, nib, que dalle, on veut que ça marche, la sécurité ? les problèmes n'arrivent qu'autres, je n'ai rien d'important.

Je le répète : "LA SECURITE EST AUSSI VOIRE PLUS IMPORTANTE QUE L'USUABILITE"

L'apothéose a été atteint avec le WIFI qui devrait permettre à tout à chacun de se connecter à l'internet sans avoir même à claquer des doigts. Suffit d'allumer son ordinateur, et ça marche. Et le pire a été que les constructeurs n'ont rien fait pour améliorer la sécurité (quoi un petit peu, mais bon....).

Passez le message à vos voisins, dîtes-leur d'utiliser de préférence WPA au lieu de WEP (sur la livebox, il me semble que la méthode par défaut est WEP), apprenez-leur les contraintes de la sécurité, comme ils l'ont apprises dans d'autres domaines, sinon nous allons vers un point de non-retour !

Si la clé WPA est modifiée toutes les heures, alors il faudrait que la méthode de crackage de clé dure moins d'une heure afin qu'elle soit utile dans ce cas.
BIen évidemment, pour le moment je pense que la durée est plus importante, du moins je l'imagine.
Reste un problème (que je viens juste de me rendre compte) : les scripts présentés ne permettent de changer que la clé WEP, qui peut être retrouvée dans les 5 minutes. Donc cette méthode n'est pas satisfaisante, et devrait plutôt être utilisée avec WPA, voire WPA2 si vous disposez d'équipement compatible. (à moins que je n'ai mal compris les scripts et qu'effectivement la méthode utilise WPA).

Seconde erreur dans laquelle l'auteur des scripts n'est pas tombée : faire un tableau de clé pour une journée (12 clé par exemple) et les changer toutes les heures, et recommencer la journée suivante avec le même tableau. Casser une clé permettrait alors de se connecter entre 12h et 13h tous les jours par exemple.

Heu le wpa avec une clef alléatoire de 63 characteres, c'est quasiment incassable ....

Pour le moment (et encore, sait-on tout ?), mais les travaux avancent vite... En gros pour le moment, ils (ceux qui font les recherches) arrivent en quelques secondes à récupérer toutes les infos qu'ils ont besoins pour le cassage de la clé : suffit de reseter une session en cours pour récupérer les premiers échanges (en envoyant un reset sur une connexion en cours, le client déconnecté va recommencer les premiers échanges d'authentification). Une fois avec ces infos, et en utilisant une carte WIFI spécifique, ils arrivent à faire 10000tests/secondes au lieu de 13 auparavant. A noter que la carte WIFI n'est utilisée que pour les calculs, car elle embarque un processeur assez puissant. Les tests se font tranquillement chez soi, les infos récupérées auparavant suffisent. Bon ok, la carte WIFI devient brûlante, mais les travaux avancent.
(source du côté du shmooCon 2006).

Peut-être veut-il que quelque-uns testent son bout de code avant de le soumettre sous forme de patch...

J'avais essayé, mais ça ne fonctionne pas. :-(

Heu, en fait je viens de me rendre compte que ces outils ne permettent d'empêcher certaines adresses IP de se connecter sur ton PC.

Mais la surveillance peut aussi se faire au niveau routeur.

De plus si elle se base sur des adresses IP identifiées, il suffit que les services de contrôle utilisent des connexions ADSL banales...

et puis après faut le temps et l'argent pour monter le dossier...

Et si je télécharge un fichier chiffré, et que je télécharge un fichier soumis aux DRMs ou un fichier avec des 0 et 1 mis n'importe comment et qui ne veulent rien dire ?

Tu viens toi même d'expliqué que tu donnais quand même dans cette configuration, l'exemple que tu cite n'est donc pas contraire a "l'idée du p2p".

Je ne donne pas dans cette configuration, je la cite comme me posant problème vis-à-vis de la loi.

Exactement comme ce qu'il se passait il y a quelques années concernant les images, où le débat a été : "est-ce qu'en changeant un pixel d'une image, je peux la reproduire sans avoir à acquitter les droits d'auteurs sur l'image originale, puisque ma nouvelle image n'est pas l'image initiale".

Moi, j'ai une question concernant les logiciels pair-à-pair. Tel que configuré de base, un tel logiciel partage le répertoire des fichiers en cours de téléchargement (Temp par exemple), mais je pense qu'il est possible de ne pas partager le répertoire des fichiers téléchargés (Incoming par exemple); dans ce cas, un utilisateur qui télécharge un fichier ne met à disposition des autres qu'une partie de ce fichier (celle qu'il a téléchargé) et non le contenu entier.

La question qui en découle est : est-ce que mettre à disposition une partie d'un fichier est punissable (de 150¤) ?

Bien entendu, cette configuration est contraire à l'idée du P2P qui est de recevoir et de donner.

Donc si je comprends bien, ça sert à rien de lire ou d'écouter de la musique aujourd'hui, on va plutôt attendre 15-20 ans quand ce sera de la culture.

Parce que pop-star dans 15-20 ans ce sera de la culture ?

ok je sors.... -> []

En dehors des geeks, la pluspart des français ne savent même pas ce que sont les DRM et ne changerons rien à leur habitudes.

et qui en cas de problème (crash disque dur, perte ipod) se diront : "bah j'ai perdu ma musique, faut que je la rachète, ce n'est pas grave ! c'est à cause des DRMs. Tant pis !"

La société de consommateur nous tranforme en mouton !

Le problème est que toi tu es conscient du problème. Mais la majorité passe outre. Les gens ont assez de problème pour s'en rajouter, alors ils se résignent à acheter les CDs. C'est le même problème que pour l'eau surtaxée ou les carburants.

Ceux qui sont sensibilisés au problème peuvent arrêter d'acheter les CDs DRMisés, ça n'empêchera pas les majors de continuer à prendre les consommateurs pour des imbéciles. Je n'achète pas les CDs protégés, ça n'empêche qu'il continue à en avoir (4/10 en tête de gondole).

ou alors il le sait !

Je ne suis pas d'accord avec toi. Il est tout à fait possible d'implémenter des MTPs au coeur de linux en utilisant des MTPs libres (voir les travaux de SUN sur le sujet).

Je n'ai pas d'empêchement pour venir, et en plus j'ai des bras. D'où ma question : "que puis-je faire pour vous aider ?"

Quel optimisme !

Les DRMs, c'est pour la musique en ligne. Mais là est tout le paradoxe de celle-ci avec Linux :
-Il est impossible de lire des fichiers DRMises avec linux
MAIS
-Il est de toute façon impossible de les acheter ( Nous vérifions si votre configuration informatique est adaptée à l'écoute de musique. sur fnac.com en ce moment même )

Et si ta femme|copinedegeek|ton homme|ton geek tourne sous Windows et achète un morceaux de musique DRMisé, alors tu ne pourras pas l'écouter sur ton linux. Je ne trouve pas ça normal !

Moralité : ce que tu écoutes sous linux n'est pas forcément acheté sous linux.

De plus, cela amène un problème paradoxal : tu es marié, d'après ton contrat de mariage, ce que tu achètes appartient aux deux. Ta femme/Ton homme achète de la musique que tu ne peux pas lire sur ton ordinateur. Un peu comme si tu achetais du pain de mie qu'il n'est possible|légal de manger que sur une des chaises de la table à manger. Et de préférence les chaises achetés dans tel magasin, tu ne peux pas fabriquer une chaise, elle ne sera pas compatible pain de mie !

Non, moi je préfère ne plus écouter leur musique, ne plus acheter des CD, des DVD etc.. Bref, je prefère boycotter plutôt que crever. Je vais pas mourrir pour ces mafieux. (et puis quoi encore ??).

Je reviens de la F**c, et je me suis amusé à regarder derrière les CDs. Sur une gondole, 2 cds sur 5 sont étiquettés "anti-copie". Ce n'est pas relativement beaucoup, quoique 40%!, mais beaucoup plus qu'il y a quelques années.

Ca m'a fait un choc à chaque fois que j'ai vu l'étiquette "Anti-copie". Je croyais que c'était que sur certains cds....

N'existe pas un site qui recense les CDs anti-copie ?

Comment tu sais que c'est sous dotclear ? je n'ai vu nulle part l'info !

bon problème résolu. En fait il s'agisait de mon application web (nocat en l'occurence) qui utilise le module perl CGI, et appelait la fonction header() sans argument.

CGI->header() plaçait donc l'entête HTTP coomme je ne le voulais pas.

CGI->header(-type=>"text/html; charset=utf-8") fait comme je veux.

Merci quand même.

L'utilisation de SSL pour HTTPs, si on prend en compte la configuration de la majorité des sites web de la planète n'a de raison d'être que d'empêcher un tiers de comprendre les communications entre le client et le serveur. Ceci ne permet pas d'authentification l'utilisateur, à moins d'utiliser l'authentification SSL par certificat, ce qui n'est pas le cas, et ce qui n'est pas non plus le but recherché par les sites HTTPS (tout le monde doit pouvoir accéder au site, mais les communications doivent être protégées).

Ainsi, l'utilisateur de SSL permet de se protéger des vers qui ne supportent pas SSL, mais pas des vers qui le supporte. Et à mon humble avis, le support ne doit pas être trop compliqué.

Donc, activer SSL permet de se protéger de l'attaque virale en cours, mais pas des prochaines.

De plus, je reviens sur la première réponse qui indique que SSL n'est pas une bonne solution, que la bonne solution est de mettre à jour ses serveurs. Oui et non. Oui, il faut mettre à jour ses serveurs. Non, ce n'est pas la solution, mais plutôt une partie de la solution, car mettre à jour vous protège des attaques connues et corrigées, mais pas des autres.

Je pense qu'il faut mettre en place plusieurs politiques de sécurité suivant le niveau que vous voulez atteindre.
La première règle de base est de mettre régulièrement à jour vos services. Ensuite, vous pouvez également vous poser la question sur la diffusion des informations. Le ver exploite une faille dans awstat. Est-ce vraiment utile/raisonnable de diffuser les statistiques de votre serveur web au monde entier ? n'auriez-vous pas interêt à protéger l'accès à cette ressource par l'utilisation d'un mot de passe ?
Ensuite, si vous voulez une protection élevée, peut-être que l'utilisation du chroot vous y aidera, à la seule condition de ne pas installer pleins d'outils dans le chroot (comme wget), et de rendre très difficile voir impossible la copie de tel outil depuis l'extérieur.

Tout ça pour dire que vous ne pourrez pas régler vos problèmes de sécurité par 1 solution, mais par une accumulation de solutions, toutes plus ou moins bonnes, mais qui chacune colmate une faille, même minuscule.

Je dois la prendre comment ta réponse, parce que c'est limite !

Ma question était plutôt quelles incidences peuvent avoir ces failles sur le système sachant que le programme ne peut avoir que accès au compte de l'utilisateur qui lance le service apache (ou autre). Et plus généralement, comment gèrent les distributions actuelles l'utilisateur apache ? a-t-il accès à un shell ? a-t-il accès à toutes les commandes du système ?

Tout pleins de questions qui ne sont pas dans la deuxième partie de la dépêche !

Parce que dans la série amalgame :

applications open-source = linux
php = linux

tout comme on a :
linux = gratuit