Ah bon, c'est maintenant légal de partager sa connexion internet?
Je ne pense pas que ça soit illégal. Il n'y a pas à ma connaissance de loi qui dit : "Ta connexion Internet point tu ne partageras !". Pas plus qu'il n'y a de loi qui interdise de prêter son téléphone par exemple.
On a par contre des CGV de fournisseurs accès qui nous interdisent de le faire. C'est différent. En fait, je pense que c'est surtout un problème de responsabilité. En faisant cela, le FAI dégage sa responsabilité en cas de pépin au niveau légal. Quoi qu'il en soit, même si ton FAI ne t'interdit pas explicitement le partage de ta connexion, il est clair que tu restes responsable de tout ce qui se passe sur ton accès. Et il serait amha très intéressant de regarder les CGV qui viennent avec cette 9box compatible FON :)
Juste une précision par rapport à mon propos dans ces deux billets.
Le premier ne vise pas spécifiquement FON, mais plus le concept de portail captif, qui ne me semble ni satisfaisant pour l'utilisateur (et en fait surtout pour lui), ni pour le gestionnaire du réseau, du point de vue de la sécurité. Le fil de commentaire sur la légalité de ce type d'offre est intéressant dans la mesure où s'il est impossible techniquement d'imputer une action à quelqu'un tellement il est simple de spoofer un utilisateur, on se demande bien ce que le propriétaire du réseau va bien pouvoir faire pour dégager sa responsabilité s'il le fallait.
Le second par contre vise spécifiquement FON dans la mesure où là, on a une faille assez énorme dans le processus d'authentification. Un utilisateur peut donc se faire voler ses identifiants et se faire usurper sur l'ensemble du réseau ensuite.
Personnellement, si je trouve le concept de communauté d'utilisateurs intéressant, mais je préfère un service comme Wifiradis[1] qui permet d'avoir une sécurité qui tient la route, même si c'est moins ouvert, en particulier pour le chalan. Ceci étant, si tous les éléments du réseau ont le même ESSID, ça devrait se gérer plutôt facilement, permettant en plus le roaming entre points d'accès, ce que FON n'assure pas, puisque le ESSID est laissé à la discrétion du propriétaire de l'accès.
Mais je me demande quand même une chose. Qu'est-ce qui t'empêche, toi, ayant besoin des fonctionnalités de PgSQL, de l'utiliser ? Qu'est-ce qui t'empêche d'utiliser Zsh en lieu et place de Bash ? Je n'utilise pas inetd et pourtant il est installé de base sur beaucoup de distribution. L'inverse pour Postfix et pleins d'autres choses. Et alors ?
Je pourrais continuer une looooooongue liste de questions de ce genre, jusqu'au "pourquoi les gens utilisent Windows alors que bon"... Mais on voit déjà les poils de troll apparaître dans l'encadrement de la porte :)
En gros, mais je me demande vraiment pourquoi on discute des choix des autres, quand bien même ils pourraient paraître ridicules, quand on peut faire les siens... Et inversement.
Ceux qui bossent "simplement dans l'informatique" vivent du software... des autres...
Mais bon, au final, c'est un écosystème. Si tu n'as pas d'utilisateur, tu ne vis pas de ton code. Donc ceux qui le distribuent t'aident aussi à vivre. On peut élargir la vision, mais au final, je trouve que distinguer les développeurs des autres pour la notion de "vivre du logiciel" me semble une vision peu étriquée. D'autant qu'un développeur utilise aussi le logiciel d'autres gens, etc...
Même si je comprends mieux la démarche de Citizendium, je trouve que c'est tout de même beaucoup d'efforts dupliqués et donc une perte de temps considérable.
Ben oui, c'est ça d'utiliser des modes non standards ;)
Le "Turbo Mode" utilise deux canaux pour doubler sa BP (il suffisait d'y penser). Donc forcément, comme les canaux se recouvrent, il faut en prendre un pile poil au milieu pour pas avoir de problème avec les candidats pour le second...
Alors que la fai n'est pas responsable, c'est bien ce que je voulais dire : D'un coté on est pas responsable, de l'autre on est responsable, alors qu'on offre le meme service.
C'est parce que le FAI est déclaré comme tel et soumis à une règlementation spécifique à son activité. Papa n'y est pas soumis et ne peut donc pas bénéficier de certains avantages qui vont avec. Beurre, argent du beurre, etc.
Y'a pleins de professions qui sont soumis à des règlementations qui leur donne certains droits que M. Toulemonde n'a pas, alors qu'il pourrait lui prendre l'idée d'offrir le même service (ou pas).
Chez moi si x=z et y =Z ; x+y=z+Z tout le temps
Je comprends, mais ici on touche à la chose humaine, dès lors, la logique mathématique...
Peut-être qu'il faudrait déclarer une profession de "fournisseur d'outils P2P" soumis à règlementation ;)
Donc dans une famille/un foyer , chaque personne doit avoir son propre accés à internet ?
Tu as du louper le mot Exemple qui introduit ce qui est justement un exemple, et non pas une généralité. J'aurais pu écrire : Papa a décidé que ses conditions blablabla...
Une loi peut trés bien dire que 'si un réseau à une quelconque mesure de chiffrement ou de protection, alors ce réseau est privé'
Oui elle pourrait, mais elle ne le fait pas, et c'est bien là le problème. Elle parle d'accès frauduleux sans vraiment expliquer ce qu'est la fraude dans ce cas, ce qui amène la jurisprudence à s'intéresser à la volonté du maître du système. C'est un peu comme la LCEN avec son motif légitime. Est-ce que c'est bien, est-ce que c'est mal, on peut en discuter (ce n'est pas mon but ici), mais c'est comme ça. Dura lex, sed lex.
D'un autre côté, retenir la présence d'une mesure de sécurité comme signe du refus d'accès mettrait les utilisateurs novices dans l'embarras s'ils ne sont pas capables de déployer de telles mesures. De fait, il faudrait alors légiférer sur la responsabilité des fournisseur de service, de logiciel, de matériel, etc. Ce qui serait probablement une bonne chose d'ailleurs, vu que la LCEN pourrait restreindre notre capacité à étudier leurs systèmes et publier les résultats. Ça rééquilibrerait un peu la balance.
Le fournisseur d'acces peut trés bien etre le parent qui fournis internet à ses enfants majeurs, doit il etre tenu responsable du comportement de ses enfants ?
S'il a souscrit l'accès en son nom, il est responsable de ce qui est fait avec l'accès, que ça ait été fait par lui ou ses enfants. En outre, responsabilité parentale, tout ça...
Te connecte plus jamais sur le net alors, parce que tu ne peux pas savoir si tu n'accede pas a des ressources privées mais non protégé par une quelconque mesure de protection
Ben non, je ne peux pas savoir, et c'est ce qui me protège (cause morale) et aussi parce que sur le web, la jurisprudence est de mon côté (Tati vs. Kitetoa). Et puis, les ressources auxquelles ont accède, on y arrive rarement par hasard.
Bref deux situations similaires, seules les variables (muettes) changent, et deux résultats diamétralement opposés
Oui, complètement. Pourquoi ? De part ce que je constate de l'utilisation qui est faite de ces deux technologies. De part le fait que quand je vois un réseau WiFi ouvert qui ne s'appelle pas orange, sfr_wifi ou autre hotspot bien connu, je ne me dis pas "chouette un accès libre" mais "encore un qui n'a pas mis de protection". De part le fait que mon raisonnement est radicalement différent face à un serveur Web, pour lequel je me dis que le contenu est effectivement à destination du public plutôt que le résultat d'une erreur de configuration.
Et étrangement, pas mal de gens avec qui j'en ai discuté son de cet avis, ce qui me fait dire que ce n'est pas si délirant que ça. Mais peut-être vis-je dans un microcosme d'illuminés (ce qui n'est pas forcément si faux) ?
Désolé mais "regles du jeu " et "maitre du système" ne font pas partie des expressions couramment utilisé en informatique, je ne sais pas en droits, mais j'ai des doutes quand meme.
Règle du jeu non je te l'accorde, c'est pour cela que j'ai évacué la première. Par contre, maître du système est un expression consacrée depuis le projet de loi Godfrain, comme le montre ce rapport préparatoir du sénat :
Et pour finir, je ne veux pas statuer sur le sujet, même si comme toi, j'aime bien avoir raison. J'expose, comme écrit plus tôt, la manière dont je comprends le texte et ce qu'en dis la jurisprudence. Maintenant, je crois qu'on a bien compris ton avis et le mien, je ne pense pas qu'il faille sortir le dé 20 et les dés 10 et finir le combat, surtout depuis le temps que je n'ai pas joué à (A)D&D.
Le terme de "règle du jeu" est certainement mal choisi, le remplacer par "conditions d'utilisation" te semble-t-il mieux ?
lorsque que FT établis un cvc en ATM pour transmettre ta connection téléphonique, c'est pas FT qui est responsable de ce que tu dis, pourtant c'est eux 'les maitres du systèmes'.
Confusion entre l'infrastructure qui fournit le service et le l'utilisation du service, qui sont deux choses bien distinctes. Idem pour l'accès Internet. Idem pour la Dédibox, etc. Le fournisseur fixe des conditions d'utilisation de son système à ses utilisateurs et éventuellement prend des mesures pour contraindre le système à cette seule utilisation.
Zorro a fait un bon rapprochement me semble-t-il entre l'expression consacrée "maître du système" et la notion de responsabilité.
tu es maître de rien du tout [...]
Tu parles de maîtrise technique là. Or la loi essaye de s'affranchir de la technique. La question porte donc plus sur la manière dont on veut utiliser le système, ici le réseau WiFi, que comment on peut contraindre ces conditions d'utilisation.
Exemple : mes conditions d'utilisation de mon réseau, c'est qu'il m'est personnel et que je dois être le seul à l'utiliser. C'est ce qui fait la différence entre l'accès public et l'accès privé aux yeux de la loi et de la jurisprudence telle que je la comprends.
Maintenant, j'ai éventuellement à ma disposition des moyens techniques pour imposer cette règle du jeu, mais ils n'y changent rien. Cette règle ne va pas changer selon que j'utilise du WEP ou du WPA.
On en revient à la séparation entre le service et l'infrastructure qui rend ce service. Quand ton FAI te fournit une box qui fait du WiFi, il te fournit un équipement qui te rend un service, qui comprend le WiFi et sa configuration (donc sa sécurisation). C'est d'ailleurs plus simple pour lui, puisque ça va lui permettre justement de décharger sa responsabilité : "la sécurisation du WiFi, c'est le problème de l'utilisateur, pas le mien", sauf peut-être le jour où quelqu'un va se retourner contre lui parce qu'il s'est fait pirater et que le FAI ne fournissait pas de mesure de protection à jour.
Maintenant, oui, ces boxes peuvent ne pas t'offrir ce que tu serais en droit d'attendre en terme de niveau de protection technique, comme ça a longtemps été le cas avec le support du WEP seulement. Mais ça n'a rien à voir avec l'utilisation que tu veux faire de ton réseau, ça a à voir avec les moyens dont tu disposes pour l'encadrer.
Ça me fait penser à la différence entre la politique de sécurité et l'implémentation de cette politique. Entre la charte d'utilisation d'un réseau et les moyens techniques qui sont mis en oeuvre pour la faire respecter. Etc.
Et comment faire pour signifier un accés libre par wifi autrement qu'en collant des étiquettes partout
En utilisant un SSID explicite, comme par exemple "wifipublic" ? Et on pourra retourner l'argument : comment faire pour signifier un accès privé, au sens de l'utilisation, pas de la technique ? Et plus loin que ça, doit-on considérer qu'un AP ouvert est public parce que finallement, on n'a pas de moyen simple de vérifier si c'est le cas ou non, même après s'être connecté ? J'aurais plutôt tendance à penser le contraire, à m'abstenir dans le doute.
au risque qu'un voisin qui utilise une config 'non chiffré' soit aussi utilisé à ta place, alors que ce ne sont pas tes règles du jeu ?
En quoi l'utilisation du réseau de mon voisin impacte-t-elle la manière dont le mien est utilisé ? Si quelqu'un utilise le réseau de mon voisin à la place du mien, public, ce sont ses règles à lui qu'on risque de ne pas respecter, pas les miennes.
le serveur web est fait pour publier de l'info , effectivement, mais on a JAMAIS dis au public
D'où le "sans mention du contraire" qui traine entre parenthèse. Qui osera (à part toi) prétendre qu'un serveur Web accessible librement sur le port TCP/80 ne doit pas être considéré comme accessible publiquement ?! C'est exactement ce qui ressort de la jurisprudence Kitetoa vs. Tati. C'est un fait communément admis sur le Net, c'est ce qui fait le Web. Dans le cas que tu évoques, tu as pris une mesure restrictive pour le rendre privé.
Ce que j'essaye de faire, maladroitement manifestement, c'est de montrer que les gens considère certains services comme publics par défaut sans même les avoir regardé et d'autres non.
Le web en est un. Quand on sait qu'un serveur Web tourne en quelque part, on ne réfrène pas son éventuelle curiosité à se demander si on peut ou non se connecter. On le fait et on attend de voir si on se prend un 403 ou une demande d'authentification, signe qu'on doit aller jouer ailleurs. C'est comme ça que c'est utilisé.
A contrario, il me semble qu'un réseau WiFi n'a pas ce côté public par défaut quand il est ouvert. Quand je vois un réseau ouvert, je n'en déduis pas naturellement qu'il s'agit d'un accès public.
Alors oui, on peux couper les cheveux en quatre et jouer sur les mots en bon gros techniciens et apprentis juristes du dimanche avec, comme tu l'écris, des mots à la mort moi le noeud à tous les coins de phrase. Ce n'est pas mon propos. Si tu veux savoir ce qu'il en est réellement, il va falloir que tu attendes que quelqu'un teste la loi (un volontaire ?).
Enfin, il y a tout de même un aspect technique que tu mentionnes rapidement. Si on a un gestionnaire automatique de connexion WiFi configuré de manière un peu laxiste (à savoir par défaut), tu peux te retrouver associé à l'insu de ton plein gré à un AP ouvert dont le propriétaire ne voudrait pas de toi. Mais (pour refaire du droit à deux balles), si tu accèdes à son système contre sa volonté, tu le fais sans le savoir et à ce titre, tu n'es pas responsable. Un ami s'est par exemple aperçu un jour de panne de son AP que son Nabaztag tournait sur celui du voisin depuis toujours :)
Et d'ailleurs c'est qui le maitre du système ? Je rapelle que l'abonné n'est PAS le propriétaire [...]
Ne pas être propriétaire n'implique pas ne pas être maître du système. Quand tu loues une DédiBox chez Free, elle ne t'appartient pas. Pourtant, tu es un peu maître de ce qui se passe dessus, non ?
Bon, maintenant, si tu prends une box ADSL et que tu peux en configurer l'accès WiFi, configuration certes limitée par les fonctionnalités qu'on te propose, tu es maître de cette partie là, tu en contrôles le fonctionnement. C'est donc toi qui définit ce qu'ils appellent les "règles du jeu", c'est à dire l'utilisation de ton réseau.
D'une manière plus générale, autant je comprends qu'on puisse considérer tous les serveurs web tournant sur le port TCP/80 comme publics (sauf mention du contraire) parce qu'un serveur web est fait pour publier de l'information, autant j'ai du mal à considérer tous les points d'accès WiFi ouverts comme publics, dans la mesure où le but du WiFi n'est pas d'offrir un accès au premier venu, mais de faire du réseau sans câble. Point. L'offre d'accès via le WiFi n'en est qu'une application.
Tout ça pour dire que si je vois un réseau WiFi ouvert avec un SSID qui n'a rien de particulier, je ne vois pas ce qui devrait me permettre d'automatiquement en déduire que la personne qui l'a installé/configuré/ceketuveu m'autorise à m'y connecter et m'en servir, à part une légère dose de mauvaise foi.
Frauduleusement implique d'après la jurisprudence, non seulement le contournement d'un dispositif de sécurité, mais aussi la consultation occulte, sans autorisation du propriétaire.
[...] La loi ne dit pas que ça doiven être protégé ou pas.
Ce n'est pas un peu contradictoire ? Si tu dois contourner un dispositif de protection, alors c'est que forcément, c'était (mal) protégé. Non ?
Ceci étant, mais je ne suis pas juriste, je comprends ces textes comme ne faisant justement pas mention du contournement de protection, la notion d'accès frauduleux semblant plus porter sur l'accord préalable du maître du système (cf. affaire Humpich vs. GIE CB) ce qui semble confirmé ici par la jurisprudence :
La Cour a retenu, tout d'abord, non le délit d'accès, ce dernier étant libre, mais le délit de maintien frauduleux dans un système de traitement automatisé de données, au sens de l'art. 3231 c. pén., dès lors qu'il suffit qu'il ait été fait sans droit et en pleine connaissance de cause, et qu'il n'est pas nécessaire que l'accès soit limité par un dispositif de protection mis en place par le "maître du système" ; I'élément moral de l'infraction était établi dès lors que les prévenus avaient eu l'intention de se maintenir dans le système au mépris de la "règle du jeu" posée par le maître du système.
Et amha ça vaut pleinement pour les réseaux WiFi, même ouverts.
Tout dépend de si tes voisins sont des hackers ou pas
Honnêtement, même avec les résultats présentés par H1kari sur le crack de WPA/WPA2 en PSK à base de chaîne FPGA, je dors très bien la nuit, même avec ses 1000 clés à la seconde :
le wpa souffre du fait qu'il n'y ait pas d'authentification du point d'accès
C'est relativement faux comme affirmation. Tu dois confondre avec le WEP justement. Tu as deux méthodes d'authentification attachées à WPA/WPA2, à savoir EAP (i.e. RADIUS en backend) et PSK.
En EAP, tu peux choisir librement (et donc en prendre une mauvaise) ta méthode d'authentification indépendament de l'AP et avoir une authentification mutuelle du client et du RADIUS et donc dans une bonne mesure de l'infrastructure. C'est le cas de méthodes comme PEAP, EAP-TLS ou EAP-TTLS.
En PSK, tu entres directement au niveau du 4-Way handshake dont la première fonction est justement de permettre à chaque partie de vérifier que l'autre possède bien la PSK par la dérivation d'une clé commune (PTK). Or, si l'AP ne possède pas cette PSK, il ne pourra pas dériver la même PTK que le client et ne pourra pas générer le 3e message du handshake correctement. La phase d'authentification va donc échouer lamentablement.
ça simplifie les attaques de type man in the middle
Tu dois faire référence au passage de Wi-Foo dans lequel ils parlent d'attaquer les méthodes EAP unilatérales comme EAP-MD5, méthodes connue pour ne pas être applicable en environnement WiFi parce qu'elle est faible, unilatérale (justement), proxifiable et ne permet pas la génération de clé de session. Et quand bien même, ce n'est pas la faute de WPA/WPA2 si l'administrateur utilise des méthodes EAP merdiques :)
A moins de coupler avec un VPN, ou avoir du 802.11i
Pour le VPN, le problème, c'est que ça commence à sérieusement compliqué l'architecture par l'ajout d'une passerelle VPN en backend.
Pour 802.11i (WPA2), je peux me tromper, mais pour autant que je sache, à quelques légères différences portant sur la négociation de paramètres de sécurité et le roaming, les mécanismes sont les mêmes. D'ailleurs, WPA2 est aussi concerné par les problèmes de PSK, et par les problèmes de TKIP si on utilise ce chiffrement prévu en option dans le standard...
WiFoo mentionne une autre attaque possible contre WPA
Les attaques que je connais sur WPA/WPA2 :
. découverte de la PSK par dictionnaire ou force brute ;
. une attaque théorique sur TKIP nécessitant la connaissance de sous-clés (PPK) internes, donc inapplicable en l'état par un attaquant extérieur ;
. une pleine tripottée de DoS sur les authentifications et la signalisation.
En gros, on finit avec quoi ? Un problème ultra-classique de choix de secret partagé et une attaque non réalisable (en l'état). Les DoS, c'est malheureusement inhérent au médium, mais ça n'excuse rien non plus.
Dire que "WPA, c'est pas encore ça" me semble largement exagéré, voire faux. WPA fait ce pour quoi il a été conçu dans un contexte pas franchement favorable (réutilisation du moteur de chiffrement WEP). Il corrige les failles de WEP en gardant la compatibilité matérielle avec un gain en sécurité tout seimplement énorme. Dire que "c'est toujours mieux que WEP" est une profonde mésestimation de ce protocole. WPA est infiniment mieux que WEP, mais cependant pas parfait, certes, vu ses fondations. Il offre donc un excellent paliatif à WEP, auquel on préfèrera un bon WPA2 en AES lorsque celui-ci est disponible sur sa plate-forme.
Sur le manque de ressources, je te rejoins, mais c'est un problème de constructeur, pas d'utilisateur, qui prend ce qu'on lui fournit.
Pour l'utilisateur, quelle est la différence entre une GUI qui te demande une passphrase WPA ou une clé WEP ? Tu prends l'interface Windows, que tu choisisses un réseau WEP ou WPA, la box qui va sortir est la même, tu ne vois même pas la différence si tu ne regardes pas la description du réseau. Donc le truc compliqué, il est aussi compliqué dans un cas que dans l'autre.
Oui le WEP a encore de beau jours devant lui, pas parce que le end-user est con. Pour lui, c'est visuellement pareil. C'est le manque de support dans les matériels et logiciels qu'il utilise qui freine (cf. commentaire suivant). Et franchement, tu ne vas pas me faire pleurer sur les constructeurs : les chipsets WiFi arrivent tout prêts à être implantés et font du WEP, du TKIP et de l'AES en hard (cf. Broadcom et autres). D'ailleurs, certains arrivent très bien à faire AP, routeur, client avec support WPA/WPA2 dans 8x6x1.7cm :
changer sa clef WEP toutes les heures pour saouler le méchant injecteur
Qu'est-ce qui est le plus chiant ? Changer sa clé WEP sur tous ses devices toutes les heures ou passer en WPA ? Personnellement, c'est l'épisode My Life, les équipements qui ne supportaient pas le WPA n'étaient pas scriptables pour parvenir à ce genre de feature, et inversement, ceux qui l'étaient supportaient le WPA, à l'exception notable de mon Zaurus, pour lequel il existe maintenant des ROMs genre OpenZaurus qui ne supportent out of the box.
au pire, tu te fais consommer ta bande passante
Je vais sûrement passer pour un parano, mais le problème que je vois, c'est pas tant la BP que je me ferais bouffer, mais surtout pourquoi on me la bouffe. Le réveil à 6h du mat' parce qu'un voisin proche aime bien les images de petites filles dévêtues ou qu'il lui a pris une envie de tester son manuel de piratage de sites web depuis ton accès, je trouverais ça moyen. Ben oui, on est responsable de ce qui sort de son accès Internet, au pénal comme au civil. La loi est assez dure comme ça ces temps-ci pour ne pas en rajouter... Je pourrais toujours faire le niais : "Ah ouais, pourtant le manuel du constructeur il dit que...". Trop gros, passera pas ? :)
D'autant que niveau traçabilité, le WiFi, c'est pas top, en ce sens que le seul identifiant que tu as sera l'adresse MAC du mec. Youpi...
Ben je dirais qu'on se situe du côté de l'utilisateur, version éclairée, qui sait qu'il doit utiliser WPA avec une clé solide.
Il est vrai que mon explication est un peu fumeuse, vu que je n'explique pas comment marche RC4 & Co. Je pense que le slide 15 de la présentation précédemment mentionnée[1] devrait t'éclairer (un peu ?).
En gros, la dernière étape de chiffrement étant un XOR entre un flux clé (keystream) et le texte clair, la connaissance du clair et du chiffré permet de retrouver ce keystream (appelé RC4 PRGA Output sur le schéma). Donc, si on veut envoyer des données arbitraires, on peut réutiliser ce keystream, dont on sait qu'il est valide, pour XORer nos données (plus 4 octets de CRC) et obtenir une trame chiffrée valide.
À partir de là, on peut commencer à jouer avec le réseau, vu qu'on peut injecter à peu près ce qu'on veut dedans. Et c'est exactement ce qu'ils font pour d'une part pour maximiser la taille des données qu'ils pourront injecter (extension du keystream via la fragmentation) et d'autre part pour stimuler le réseau afin qu'il génére du trafic, condition nécessaire au cassage de la clé WEP.
Comme partout ou une clé partagée est utilisée, la sécurité de l'ensemble ne repose que sur la solidité de la clé partagée en question. Du coup, je ne saurais que te renvoyer au nombreuses diatribes sur le choix des mots de passe, etc.
Avec l'avantage certain que dans le cas de WPA/WPA2, tu n'entres ta clé partagée (PSK) qu'une fois à la configuration initiale et que tu n'as donc pas besoin de la retenir, ce qui te permet d'en prendre une _très_ compliquée. Tu as droit à 63 caractères ASCII ou parfois (selon les interfaces) directement 256 bits. Profites-en, et tu pourras dormir tranquille ;)
Concernant cette attaque, il s'agit d'une méthode simple pour récupérer 1504 octets de keystream RC4 de manière à pouvoir commencer à injecter des paquets sur le réseau. Andreas Bittau a déjà présenté ça à la dernière Toorcon, et j'en parle dans mes dernières confs, comme celle-ci (cf. slide 19) :
L'idée, c'est que le payload chiffré d'une trame 802.11 commence par un entête LLC/SNAP sont les 6 premiers octets sont fixes et les deux suivants sont un ethertype simple à deviner. En effet, les communications sont essentiellement de l'IP (0x800) avec quelques paquets ARP (0x806) simples à détecter. Ce qui veut dire que sur un paquet IP lambda, on a un clair connu sur les 8 premiers octets (ou plus sur un paquet ARP vu la forme de son entête) qui permet donc de resortir 8 octets de keystream RC4, qu'on va pouvoir réutiliser pour chiffrer 4 octets de données et leur CRC.
À partir de là, il va exploiter le fonctionnement de la fragmentation disponible dans 802.11. Lorsqu'un AP reçoit des fragments chiffrés, il les déchiffre, les vérifie et reassemble la trame originale avant de la chiffrer entière pour la renvoyer sur le réseau (si elle doit y revenir). De fait, si on prend un payload de 64 octets d'une trame destinée au réseau WiFi, on peut le découper en 16 fragments de 4 octets et chiffrer chaque fragment avec notre petit morceau de keystream découvert précédemment. L'AP va donc recevoir les fragments, reconstituer la trame et la rejouer entière. On obtient alors un nouveau clair connu, mais cette fois sur 68 octets (64 data + CRC), puisqu'on connait le contenu clair de cette trame.
On peut alors rejouer l'attaque avec des fragments plus gros pour obtenir 64*16+4 = 1028 octets au tour suivant et finallement atteindre la MTU au 3e tour, ce qui est faisable dans les deux premières secondes. Ensuite, l'outil va essayer soit de sortir sur Internet, soit de déchiffrer une adresse IP présente sur le réseau (environ 30 secondes) de manière à faire générer du trafic, soit en communicant avec un hôte contrôlé à l'extérieur, soit en floodant l'adresse locale découverte de requêtes ARP pour générer du trafic qui sera filé à aircrack pour récupérer la clé WEP.
En définitive, l'essentiel de papier porte sur une attaque permettant d'injecter de générer du trafic pour alimenter Aircrack. À la différence de aireplay, elle ne nécessite pas de trafic (ARP en particulier) ou de situation particulière. C'est une exploitation brillante d'une fonctionnalité assez peu connue de 802.11.
Maintenant, quand on lit les articles, on a l'impression que c'est une révolution., ce qui n'est pas le cas comme le mentionnent les auteurs dans leur conclusion :
Walker's and Simon's attack on keystream re-use were never considered as a threat. A year later, Arbaugh, and Borisov et al. resurrected thoses attacks bu noting the vulnerability in Shared Key authentication. [...] Today, we resurrect the 2000 keystream re-use attacks once more.
Mais bon, le WEP, comme tu le dis, a un remplaçant qui tient la route depuis 3 ans et est connu pour être définitivement trop faible depuis 2001 avec les travaux d'Arbaugh, Borisov et al., et Fluhrer et al., et plus tard de Ikari, Korek, etc. (2004). Ce n'est qu'une technique, très ingénieuse et efficace, et un outil de plus parmi pleins d'autres pour lui faire la peau. Mais bon, si c'est celle qui fait bouger les gens, alors tant mieux. Parce que même la pléthore de démos et vidéos de crack de WEP en moins de 15 minutes ne semblaient pas émouvoir grand monde...
Mais ils peuvent continuer à spamer avec leurs propres domaines.
Sachant que les plus gros spammers de la planète sont des gens qui ont pignon sur rue, utilisent leurs propres domaines, avec leurs propres serveurs, ça ne les empêchera pas de spammer. Le Sender-ID contre le spam, c'est ni plus ni moins que de la poudre aux yeux, genre sparadra sur un plaie béante.
Une étude (j'ai la flemme de chercher) avait été faite sur les gens qui utilisaient le Sender-ID. Sur le volume global de mails étudiés, il apparaissait que plus de 50% du trafic était du spam... CQFD...
En plus, le Sender-ID, ça casse les mailing-lists, dont le remailer ne fait qu'envoyer du mail dont le domaine source est celui de l'émetteur du message, donc forcément pas celui de l'hébergeur de la mailing-list.
On ne peut pas demander à Google de ralentir sa fourniture de service pour "laisser de la place aux autres". C'est d'une part aux concurrent qu'il appartient de fournir des services de qualité, et d'autre part aux utilisateurs qu'il appartient d'utiliser ces derniers.
Chez Google, j'utilise les moteurs de recherche et parfois Google Maps, parce que je les trouve encore au dessus de ce que proposent les autres.
# Désolé, je ne peux pas me retenir...
Posté par Cédric Blancher . En réponse au journal Coup de gueule contre club-internet. Évalué à 3.
Va donc prendre les eaux ailleurs :)
[^] # Re: C'est le blog de Thierry Stoer ?
Posté par Cédric Blancher . En réponse au journal Les standards et l'interopérabilité dans l'exploration spatiale. Évalué à 4.
Le kilo n'est pas une unité. L'unité, c'est le kilogramme.
</capilotraction
[^] # Re: Coming soon...
Posté par Cédric Blancher . En réponse au journal Les standards et l'interopérabilité dans l'exploration spatiale. Évalué à 5.
Poisson d'avril !
~~~~~> [ ]
[^] # Re: Légalité?
Posté par Cédric Blancher . En réponse au journal Le Wifi à Fon la caisse.... Évalué à 1.
Je ne pense pas que ça soit illégal. Il n'y a pas à ma connaissance de loi qui dit : "Ta connexion Internet point tu ne partageras !". Pas plus qu'il n'y a de loi qui interdise de prêter son téléphone par exemple.
On a par contre des CGV de fournisseurs accès qui nous interdisent de le faire. C'est différent. En fait, je pense que c'est surtout un problème de responsabilité. En faisant cela, le FAI dégage sa responsabilité en cas de pépin au niveau légal. Quoi qu'il en soit, même si ton FAI ne t'interdit pas explicitement le partage de ta connexion, il est clair que tu restes responsable de tout ce qui se passe sur ton accès. Et il serait amha très intéressant de regarder les CGV qui viennent avec cette 9box compatible FON :)
[^] # Re: Sécurité
Posté par Cédric Blancher . En réponse au journal Le Wifi à Fon la caisse.... Évalué à 2.
Le premier ne vise pas spécifiquement FON, mais plus le concept de portail captif, qui ne me semble ni satisfaisant pour l'utilisateur (et en fait surtout pour lui), ni pour le gestionnaire du réseau, du point de vue de la sécurité. Le fil de commentaire sur la légalité de ce type d'offre est intéressant dans la mesure où s'il est impossible techniquement d'imputer une action à quelqu'un tellement il est simple de spoofer un utilisateur, on se demande bien ce que le propriétaire du réseau va bien pouvoir faire pour dégager sa responsabilité s'il le fallait.
Le second par contre vise spécifiquement FON dans la mesure où là, on a une faille assez énorme dans le processus d'authentification. Un utilisateur peut donc se faire voler ses identifiants et se faire usurper sur l'ensemble du réseau ensuite.
Personnellement, si je trouve le concept de communauté d'utilisateurs intéressant, mais je préfère un service comme Wifiradis[1] qui permet d'avoir une sécurité qui tient la route, même si c'est moins ouvert, en particulier pour le chalan. Ceci étant, si tous les éléments du réseau ont le même ESSID, ça devrait se gérer plutôt facilement, permettant en plus le roaming entre points d'accès, ce que FON n'assure pas, puisque le ESSID est laissé à la discrétion du propriétaire de l'accès.
[1] http://www.wifiradis.net/
[^] # Re: Pour MySQL...
Posté par Cédric Blancher . En réponse au journal Les choix étranges du libre. Évalué à 2.
Je pourrais continuer une looooooongue liste de questions de ce genre, jusqu'au "pourquoi les gens utilisent Windows alors que bon"... Mais on voit déjà les poils de troll apparaître dans l'encadrement de la porte :)
En gros, mais je me demande vraiment pourquoi on discute des choix des autres, quand bien même ils pourraient paraître ridicules, quand on peut faire les siens... Et inversement.
[^] # Re: 01 INFORMATIQUE N°1871 du 8 septembre 2006
Posté par Cédric Blancher . En réponse au journal 800 000 informaticiens qui travaillent dans le "code" en France ?. Évalué à 3.
Mais bon, au final, c'est un écosystème. Si tu n'as pas d'utilisateur, tu ne vis pas de ton code. Donc ceux qui le distribuent t'aident aussi à vivre. On peut élargir la vision, mais au final, je trouve que distinguer les développeurs des autres pour la notion de "vivre du logiciel" me semble une vision peu étriquée. D'autant qu'un développeur utilise aussi le logiciel d'autres gens, etc...
# Dans le même genre...
Posté par Cédric Blancher . En réponse au journal Fork de Wikipedia. Évalué à 1.
http://www.cryptodox.com/
Comme si Wikipedia ne fournissait pas déjà une tonne d'articles sur le sujet :
http://en.wikipedia.org/wiki/Portal:Cryptography
Même si je comprends mieux la démarche de Citizendium, je trouve que c'est tout de même beaucoup d'efforts dupliqués et donc une perte de temps considérable.
[^] # Re: On tient un spécialiste alors j'en profite...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 3.
Le "Turbo Mode" utilise deux canaux pour doubler sa BP (il suffisait d'y penser). Donc forcément, comme les canaux se recouvrent, il faut en prendre un pile poil au milieu pour pas avoir de problème avec les candidats pour le second...
Et paf...
[^] # Re: Wifi et DRM
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 4.
C'est parce que le FAI est déclaré comme tel et soumis à une règlementation spécifique à son activité. Papa n'y est pas soumis et ne peut donc pas bénéficier de certains avantages qui vont avec. Beurre, argent du beurre, etc.
Y'a pleins de professions qui sont soumis à des règlementations qui leur donne certains droits que M. Toulemonde n'a pas, alors qu'il pourrait lui prendre l'idée d'offrir le même service (ou pas).
Chez moi si x=z et y =Z ; x+y=z+Z tout le temps
Je comprends, mais ici on touche à la chose humaine, dès lors, la logique mathématique...
Peut-être qu'il faudrait déclarer une profession de "fournisseur d'outils P2P" soumis à règlementation ;)
[^] # Re: Wifi et DRM
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 2.
Tu as du louper le mot Exemple qui introduit ce qui est justement un exemple, et non pas une généralité. J'aurais pu écrire : Papa a décidé que ses conditions blablabla...
Une loi peut trés bien dire que 'si un réseau à une quelconque mesure de chiffrement ou de protection, alors ce réseau est privé'
Oui elle pourrait, mais elle ne le fait pas, et c'est bien là le problème. Elle parle d'accès frauduleux sans vraiment expliquer ce qu'est la fraude dans ce cas, ce qui amène la jurisprudence à s'intéresser à la volonté du maître du système. C'est un peu comme la LCEN avec son motif légitime. Est-ce que c'est bien, est-ce que c'est mal, on peut en discuter (ce n'est pas mon but ici), mais c'est comme ça. Dura lex, sed lex.
D'un autre côté, retenir la présence d'une mesure de sécurité comme signe du refus d'accès mettrait les utilisateurs novices dans l'embarras s'ils ne sont pas capables de déployer de telles mesures. De fait, il faudrait alors légiférer sur la responsabilité des fournisseur de service, de logiciel, de matériel, etc. Ce qui serait probablement une bonne chose d'ailleurs, vu que la LCEN pourrait restreindre notre capacité à étudier leurs systèmes et publier les résultats. Ça rééquilibrerait un peu la balance.
Le fournisseur d'acces peut trés bien etre le parent qui fournis internet à ses enfants majeurs, doit il etre tenu responsable du comportement de ses enfants ?
S'il a souscrit l'accès en son nom, il est responsable de ce qui est fait avec l'accès, que ça ait été fait par lui ou ses enfants. En outre, responsabilité parentale, tout ça...
Te connecte plus jamais sur le net alors, parce que tu ne peux pas savoir si tu n'accede pas a des ressources privées mais non protégé par une quelconque mesure de protection
Ben non, je ne peux pas savoir, et c'est ce qui me protège (cause morale) et aussi parce que sur le web, la jurisprudence est de mon côté (Tati vs. Kitetoa). Et puis, les ressources auxquelles ont accède, on y arrive rarement par hasard.
Bref deux situations similaires, seules les variables (muettes) changent, et deux résultats diamétralement opposés
Oui, complètement. Pourquoi ? De part ce que je constate de l'utilisation qui est faite de ces deux technologies. De part le fait que quand je vois un réseau WiFi ouvert qui ne s'appelle pas orange, sfr_wifi ou autre hotspot bien connu, je ne me dis pas "chouette un accès libre" mais "encore un qui n'a pas mis de protection". De part le fait que mon raisonnement est radicalement différent face à un serveur Web, pour lequel je me dis que le contenu est effectivement à destination du public plutôt que le résultat d'une erreur de configuration.
Et étrangement, pas mal de gens avec qui j'en ai discuté son de cet avis, ce qui me fait dire que ce n'est pas si délirant que ça. Mais peut-être vis-je dans un microcosme d'illuminés (ce qui n'est pas forcément si faux) ?
Désolé mais "regles du jeu " et "maitre du système" ne font pas partie des expressions couramment utilisé en informatique, je ne sais pas en droits, mais j'ai des doutes quand meme.
Règle du jeu non je te l'accorde, c'est pour cela que j'ai évacué la première. Par contre, maître du système est un expression consacrée depuis le projet de loi Godfrain, comme le montre ce rapport préparatoir du sénat :
http://www.senat.fr/rap/l87-3/l87-3.html
Désolé, c'est comme ça, et c'est pour ça qu'on la retrouve dans les jurisprudences comme, entre autres (STFW), le jugement de l'affaire Humpich :
http://www.legalis.net/jurisprudence-decision.php3?id_articl(...)
Allez deux autres liens assez intéressant sur le sujet :
http://www.net-iris.fr/veille-juridique/doctrine/10853/acces(...)
http://www.e-juristes.org/article.php3?id_article=721
Et pour finir, je ne veux pas statuer sur le sujet, même si comme toi, j'aime bien avoir raison. J'expose, comme écrit plus tôt, la manière dont je comprends le texte et ce qu'en dis la jurisprudence. Maintenant, je crois qu'on a bien compris ton avis et le mien, je ne pense pas qu'il faille sortir le dé 20 et les dés 10 et finir le combat, surtout depuis le temps que je n'ai pas joué à (A)D&D.
[^] # Re: Wifi et DRM
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 4.
lorsque que FT établis un cvc en ATM pour transmettre ta connection téléphonique, c'est pas FT qui est responsable de ce que tu dis, pourtant c'est eux 'les maitres du systèmes'.
Confusion entre l'infrastructure qui fournit le service et le l'utilisation du service, qui sont deux choses bien distinctes. Idem pour l'accès Internet. Idem pour la Dédibox, etc. Le fournisseur fixe des conditions d'utilisation de son système à ses utilisateurs et éventuellement prend des mesures pour contraindre le système à cette seule utilisation.
Zorro a fait un bon rapprochement me semble-t-il entre l'expression consacrée "maître du système" et la notion de responsabilité.
tu es maître de rien du tout [...]
Tu parles de maîtrise technique là. Or la loi essaye de s'affranchir de la technique. La question porte donc plus sur la manière dont on veut utiliser le système, ici le réseau WiFi, que comment on peut contraindre ces conditions d'utilisation.
Exemple : mes conditions d'utilisation de mon réseau, c'est qu'il m'est personnel et que je dois être le seul à l'utiliser. C'est ce qui fait la différence entre l'accès public et l'accès privé aux yeux de la loi et de la jurisprudence telle que je la comprends.
Maintenant, j'ai éventuellement à ma disposition des moyens techniques pour imposer cette règle du jeu, mais ils n'y changent rien. Cette règle ne va pas changer selon que j'utilise du WEP ou du WPA.
On en revient à la séparation entre le service et l'infrastructure qui rend ce service. Quand ton FAI te fournit une box qui fait du WiFi, il te fournit un équipement qui te rend un service, qui comprend le WiFi et sa configuration (donc sa sécurisation). C'est d'ailleurs plus simple pour lui, puisque ça va lui permettre justement de décharger sa responsabilité : "la sécurisation du WiFi, c'est le problème de l'utilisateur, pas le mien", sauf peut-être le jour où quelqu'un va se retourner contre lui parce qu'il s'est fait pirater et que le FAI ne fournissait pas de mesure de protection à jour.
Maintenant, oui, ces boxes peuvent ne pas t'offrir ce que tu serais en droit d'attendre en terme de niveau de protection technique, comme ça a longtemps été le cas avec le support du WEP seulement. Mais ça n'a rien à voir avec l'utilisation que tu veux faire de ton réseau, ça a à voir avec les moyens dont tu disposes pour l'encadrer.
Ça me fait penser à la différence entre la politique de sécurité et l'implémentation de cette politique. Entre la charte d'utilisation d'un réseau et les moyens techniques qui sont mis en oeuvre pour la faire respecter. Etc.
Et comment faire pour signifier un accés libre par wifi autrement qu'en collant des étiquettes partout
En utilisant un SSID explicite, comme par exemple "wifipublic" ? Et on pourra retourner l'argument : comment faire pour signifier un accès privé, au sens de l'utilisation, pas de la technique ? Et plus loin que ça, doit-on considérer qu'un AP ouvert est public parce que finallement, on n'a pas de moyen simple de vérifier si c'est le cas ou non, même après s'être connecté ? J'aurais plutôt tendance à penser le contraire, à m'abstenir dans le doute.
au risque qu'un voisin qui utilise une config 'non chiffré' soit aussi utilisé à ta place, alors que ce ne sont pas tes règles du jeu ?
En quoi l'utilisation du réseau de mon voisin impacte-t-elle la manière dont le mien est utilisé ? Si quelqu'un utilise le réseau de mon voisin à la place du mien, public, ce sont ses règles à lui qu'on risque de ne pas respecter, pas les miennes.
le serveur web est fait pour publier de l'info , effectivement, mais on a JAMAIS dis au public
D'où le "sans mention du contraire" qui traine entre parenthèse. Qui osera (à part toi) prétendre qu'un serveur Web accessible librement sur le port TCP/80 ne doit pas être considéré comme accessible publiquement ?! C'est exactement ce qui ressort de la jurisprudence Kitetoa vs. Tati. C'est un fait communément admis sur le Net, c'est ce qui fait le Web. Dans le cas que tu évoques, tu as pris une mesure restrictive pour le rendre privé.
Ce que j'essaye de faire, maladroitement manifestement, c'est de montrer que les gens considère certains services comme publics par défaut sans même les avoir regardé et d'autres non.
Le web en est un. Quand on sait qu'un serveur Web tourne en quelque part, on ne réfrène pas son éventuelle curiosité à se demander si on peut ou non se connecter. On le fait et on attend de voir si on se prend un 403 ou une demande d'authentification, signe qu'on doit aller jouer ailleurs. C'est comme ça que c'est utilisé.
A contrario, il me semble qu'un réseau WiFi n'a pas ce côté public par défaut quand il est ouvert. Quand je vois un réseau ouvert, je n'en déduis pas naturellement qu'il s'agit d'un accès public.
Alors oui, on peux couper les cheveux en quatre et jouer sur les mots en bon gros techniciens et apprentis juristes du dimanche avec, comme tu l'écris, des mots à la mort moi le noeud à tous les coins de phrase. Ce n'est pas mon propos. Si tu veux savoir ce qu'il en est réellement, il va falloir que tu attendes que quelqu'un teste la loi (un volontaire ?).
Enfin, il y a tout de même un aspect technique que tu mentionnes rapidement. Si on a un gestionnaire automatique de connexion WiFi configuré de manière un peu laxiste (à savoir par défaut), tu peux te retrouver associé à l'insu de ton plein gré à un AP ouvert dont le propriétaire ne voudrait pas de toi. Mais (pour refaire du droit à deux balles), si tu accèdes à son système contre sa volonté, tu le fais sans le savoir et à ce titre, tu n'es pas responsable. Un ami s'est par exemple aperçu un jour de panne de son AP que son Nabaztag tournait sur celui du voisin depuis toujours :)
[^] # Re: On tient un spécialiste alors j'en profite...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 2.
[^] # Re: Wifi et DRM
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 5.
Ne pas être propriétaire n'implique pas ne pas être maître du système. Quand tu loues une DédiBox chez Free, elle ne t'appartient pas. Pourtant, tu es un peu maître de ce qui se passe dessus, non ?
Bon, maintenant, si tu prends une box ADSL et que tu peux en configurer l'accès WiFi, configuration certes limitée par les fonctionnalités qu'on te propose, tu es maître de cette partie là, tu en contrôles le fonctionnement. C'est donc toi qui définit ce qu'ils appellent les "règles du jeu", c'est à dire l'utilisation de ton réseau.
D'une manière plus générale, autant je comprends qu'on puisse considérer tous les serveurs web tournant sur le port TCP/80 comme publics (sauf mention du contraire) parce qu'un serveur web est fait pour publier de l'information, autant j'ai du mal à considérer tous les points d'accès WiFi ouverts comme publics, dans la mesure où le but du WiFi n'est pas d'offrir un accès au premier venu, mais de faire du réseau sans câble. Point. L'offre d'accès via le WiFi n'en est qu'une application.
Tout ça pour dire que si je vois un réseau WiFi ouvert avec un SSID qui n'a rien de particulier, je ne vois pas ce qui devrait me permettre d'automatiquement en déduire que la personne qui l'a installé/configuré/ceketuveu m'autorise à m'y connecter et m'en servir, à part une légère dose de mauvaise foi.
[^] # Re: Ma politique WEP
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 3.
Kismet sait faire aussi. Il suffit de le laisser tourner. Et il te fournira aussi la trace pcap.
[^] # Re: Wifi et DRM
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 3.
[...]
La loi ne dit pas que ça doiven être protégé ou pas.
Ce n'est pas un peu contradictoire ? Si tu dois contourner un dispositif de protection, alors c'est que forcément, c'était (mal) protégé. Non ?
Ceci étant, mais je ne suis pas juriste, je comprends ces textes comme ne faisant justement pas mention du contournement de protection, la notion d'accès frauduleux semblant plus porter sur l'accord préalable du maître du système (cf. affaire Humpich vs. GIE CB) ce qui semble confirmé ici par la jurisprudence :
http://www.dit.presse.fr/data/french/fold/dit963/jurispru/ju(...)
Et amha ça vaut pleinement pour les réseaux WiFi, même ouverts.
[^] # Re: On tient un spécialiste alors j'en profite...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 10.
Honnêtement, même avec les résultats présentés par H1kari sur le crack de WPA/WPA2 en PSK à base de chaîne FPGA, je dors très bien la nuit, même avec ses 1000 clés à la seconde :
http://recon.cx/en/f/dhulton-breaking-wifi-faster.ppt
le wpa souffre du fait qu'il n'y ait pas d'authentification du point d'accès
C'est relativement faux comme affirmation. Tu dois confondre avec le WEP justement. Tu as deux méthodes d'authentification attachées à WPA/WPA2, à savoir EAP (i.e. RADIUS en backend) et PSK.
En EAP, tu peux choisir librement (et donc en prendre une mauvaise) ta méthode d'authentification indépendament de l'AP et avoir une authentification mutuelle du client et du RADIUS et donc dans une bonne mesure de l'infrastructure. C'est le cas de méthodes comme PEAP, EAP-TLS ou EAP-TTLS.
En PSK, tu entres directement au niveau du 4-Way handshake dont la première fonction est justement de permettre à chaque partie de vérifier que l'autre possède bien la PSK par la dérivation d'une clé commune (PTK). Or, si l'AP ne possède pas cette PSK, il ne pourra pas dériver la même PTK que le client et ne pourra pas générer le 3e message du handshake correctement. La phase d'authentification va donc échouer lamentablement.
ça simplifie les attaques de type man in the middle
Tu dois faire référence au passage de Wi-Foo dans lequel ils parlent d'attaquer les méthodes EAP unilatérales comme EAP-MD5, méthodes connue pour ne pas être applicable en environnement WiFi parce qu'elle est faible, unilatérale (justement), proxifiable et ne permet pas la génération de clé de session. Et quand bien même, ce n'est pas la faute de WPA/WPA2 si l'administrateur utilise des méthodes EAP merdiques :)
A moins de coupler avec un VPN, ou avoir du 802.11i
Pour le VPN, le problème, c'est que ça commence à sérieusement compliqué l'architecture par l'ajout d'une passerelle VPN en backend.
Pour 802.11i (WPA2), je peux me tromper, mais pour autant que je sache, à quelques légères différences portant sur la négociation de paramètres de sécurité et le roaming, les mécanismes sont les mêmes. D'ailleurs, WPA2 est aussi concerné par les problèmes de PSK, et par les problèmes de TKIP si on utilise ce chiffrement prévu en option dans le standard...
WiFoo mentionne une autre attaque possible contre WPA
Les attaques que je connais sur WPA/WPA2 :
. découverte de la PSK par dictionnaire ou force brute ;
. une attaque théorique sur TKIP nécessitant la connaissance de sous-clés (PPK) internes, donc inapplicable en l'état par un attaquant extérieur ;
. une pleine tripottée de DoS sur les authentifications et la signalisation.
En gros, on finit avec quoi ? Un problème ultra-classique de choix de secret partagé et une attaque non réalisable (en l'état). Les DoS, c'est malheureusement inhérent au médium, mais ça n'excuse rien non plus.
Dire que "WPA, c'est pas encore ça" me semble largement exagéré, voire faux. WPA fait ce pour quoi il a été conçu dans un contexte pas franchement favorable (réutilisation du moteur de chiffrement WEP). Il corrige les failles de WEP en gardant la compatibilité matérielle avec un gain en sécurité tout seimplement énorme. Dire que "c'est toujours mieux que WEP" est une profonde mésestimation de ce protocole. WPA est infiniment mieux que WEP, mais cependant pas parfait, certes, vu ses fondations. Il offre donc un excellent paliatif à WEP, auquel on préfèrera un bon WPA2 en AES lorsque celui-ci est disponible sur sa plate-forme.
[^] # Re: Ça fait longtemps qu'on sait que WEP est inutile...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 3.
Pour l'utilisateur, quelle est la différence entre une GUI qui te demande une passphrase WPA ou une clé WEP ? Tu prends l'interface Windows, que tu choisisses un réseau WEP ou WPA, la box qui va sortir est la même, tu ne vois même pas la différence si tu ne regardes pas la description du réseau. Donc le truc compliqué, il est aussi compliqué dans un cas que dans l'autre.
Oui le WEP a encore de beau jours devant lui, pas parce que le end-user est con. Pour lui, c'est visuellement pareil. C'est le manque de support dans les matériels et logiciels qu'il utilise qui freine (cf. commentaire suivant). Et franchement, tu ne vas pas me faire pleurer sur les constructeurs : les chipsets WiFi arrivent tout prêts à être implantés et font du WEP, du TKIP et de l'AES en hard (cf. Broadcom et autres). D'ailleurs, certains arrivent très bien à faire AP, routeur, client avec support WPA/WPA2 dans 8x6x1.7cm :
http://www.dlink.com/products/?pid=346
[^] # Re: Ça fait longtemps qu'on sait que WEP est inutile...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 7.
Qu'est-ce qui est le plus chiant ? Changer sa clé WEP sur tous ses devices toutes les heures ou passer en WPA ? Personnellement, c'est l'épisode My Life, les équipements qui ne supportaient pas le WPA n'étaient pas scriptables pour parvenir à ce genre de feature, et inversement, ceux qui l'étaient supportaient le WPA, à l'exception notable de mon Zaurus, pour lequel il existe maintenant des ROMs genre OpenZaurus qui ne supportent out of the box.
au pire, tu te fais consommer ta bande passante
Je vais sûrement passer pour un parano, mais le problème que je vois, c'est pas tant la BP que je me ferais bouffer, mais surtout pourquoi on me la bouffe. Le réveil à 6h du mat' parce qu'un voisin proche aime bien les images de petites filles dévêtues ou qu'il lui a pris une envie de tester son manuel de piratage de sites web depuis ton accès, je trouverais ça moyen. Ben oui, on est responsable de ce qui sort de son accès Internet, au pénal comme au civil. La loi est assez dure comme ça ces temps-ci pour ne pas en rajouter... Je pourrais toujours faire le niais : "Ah ouais, pourtant le manuel du constructeur il dit que...". Trop gros, passera pas ? :)
D'autant que niveau traçabilité, le WiFi, c'est pas top, en ce sens que le seul identifiant que tu as sera l'adresse MAC du mec. Youpi...
[^] # Re: Ça fait longtemps qu'on sait que WEP est inutile...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 10.
Il est vrai que mon explication est un peu fumeuse, vu que je n'explique pas comment marche RC4 & Co. Je pense que le slide 15 de la présentation précédemment mentionnée[1] devrait t'éclairer (un peu ?).
En gros, la dernière étape de chiffrement étant un XOR entre un flux clé (keystream) et le texte clair, la connaissance du clair et du chiffré permet de retrouver ce keystream (appelé RC4 PRGA Output sur le schéma). Donc, si on veut envoyer des données arbitraires, on peut réutiliser ce keystream, dont on sait qu'il est valide, pour XORer nos données (plus 4 octets de CRC) et obtenir une trame chiffrée valide.
À partir de là, on peut commencer à jouer avec le réseau, vu qu'on peut injecter à peu près ce qu'on veut dedans. Et c'est exactement ce qu'ils font pour d'une part pour maximiser la taille des données qu'ils pourront injecter (extension du keystream via la fragmentation) et d'autre part pour stimuler le réseau afin qu'il génére du trafic, condition nécessaire au cassage de la clé WEP.
[1] http://sid.rstack.org/pres/0602_Securecon_WirelessInjection.(...)
[^] # Re: On tient un spécialiste alors j'en profite...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 2.
Avec l'avantage certain que dans le cas de WPA/WPA2, tu n'entres ta clé partagée (PSK) qu'une fois à la configuration initiale et que tu n'as donc pas besoin de la retenir, ce qui te permet d'en prendre une _très_ compliquée. Tu as droit à 63 caractères ASCII ou parfois (selon les interfaces) directement 256 bits. Profites-en, et tu pourras dormir tranquille ;)
# Ça fait longtemps qu'on sait que WEP est inutile...
Posté par Cédric Blancher . En réponse à la dépêche Un dernier clou dans le cercueil du WEP. Évalué à 10.
http://sid.rstack.org/pres/0602_Securecon_WirelessInjection.(...)
L'idée, c'est que le payload chiffré d'une trame 802.11 commence par un entête LLC/SNAP sont les 6 premiers octets sont fixes et les deux suivants sont un ethertype simple à deviner. En effet, les communications sont essentiellement de l'IP (0x800) avec quelques paquets ARP (0x806) simples à détecter. Ce qui veut dire que sur un paquet IP lambda, on a un clair connu sur les 8 premiers octets (ou plus sur un paquet ARP vu la forme de son entête) qui permet donc de resortir 8 octets de keystream RC4, qu'on va pouvoir réutiliser pour chiffrer 4 octets de données et leur CRC.
À partir de là, il va exploiter le fonctionnement de la fragmentation disponible dans 802.11. Lorsqu'un AP reçoit des fragments chiffrés, il les déchiffre, les vérifie et reassemble la trame originale avant de la chiffrer entière pour la renvoyer sur le réseau (si elle doit y revenir). De fait, si on prend un payload de 64 octets d'une trame destinée au réseau WiFi, on peut le découper en 16 fragments de 4 octets et chiffrer chaque fragment avec notre petit morceau de keystream découvert précédemment. L'AP va donc recevoir les fragments, reconstituer la trame et la rejouer entière. On obtient alors un nouveau clair connu, mais cette fois sur 68 octets (64 data + CRC), puisqu'on connait le contenu clair de cette trame.
On peut alors rejouer l'attaque avec des fragments plus gros pour obtenir 64*16+4 = 1028 octets au tour suivant et finallement atteindre la MTU au 3e tour, ce qui est faisable dans les deux premières secondes. Ensuite, l'outil va essayer soit de sortir sur Internet, soit de déchiffrer une adresse IP présente sur le réseau (environ 30 secondes) de manière à faire générer du trafic, soit en communicant avec un hôte contrôlé à l'extérieur, soit en floodant l'adresse locale découverte de requêtes ARP pour générer du trafic qui sera filé à aircrack pour récupérer la clé WEP.
En définitive, l'essentiel de papier porte sur une attaque permettant d'injecter de générer du trafic pour alimenter Aircrack. À la différence de aireplay, elle ne nécessite pas de trafic (ARP en particulier) ou de situation particulière. C'est une exploitation brillante d'une fonctionnalité assez peu connue de 802.11.
Maintenant, quand on lit les articles, on a l'impression que c'est une révolution., ce qui n'est pas le cas comme le mentionnent les auteurs dans leur conclusion :
Mais bon, le WEP, comme tu le dis, a un remplaçant qui tient la route depuis 3 ans et est connu pour être définitivement trop faible depuis 2001 avec les travaux d'Arbaugh, Borisov et al., et Fluhrer et al., et plus tard de Ikari, Korek, etc. (2004). Ce n'est qu'une technique, très ingénieuse et efficace, et un outil de plus parmi pleins d'autres pour lui faire la peau. Mais bon, si c'est celle qui fait bouger les gens, alors tant mieux. Parce que même la pléthore de démos et vidéos de crack de WEP en moins de 15 minutes ne semblaient pas émouvoir grand monde...
[^] # Re: MS touch...
Posté par Cédric Blancher . En réponse au journal Ouverture du site "Signal Spam". Évalué à 3.
Sachant que les plus gros spammers de la planète sont des gens qui ont pignon sur rue, utilisent leurs propres domaines, avec leurs propres serveurs, ça ne les empêchera pas de spammer. Le Sender-ID contre le spam, c'est ni plus ni moins que de la poudre aux yeux, genre sparadra sur un plaie béante.
Une étude (j'ai la flemme de chercher) avait été faite sur les gens qui utilisaient le Sender-ID. Sur le volume global de mails étudiés, il apparaissait que plus de 50% du trafic était du spam... CQFD...
En plus, le Sender-ID, ça casse les mailing-lists, dont le remailer ne fait qu'envoyer du mail dont le domaine source est celui de l'émetteur du message, donc forcément pas celui de l'hébergeur de la mailing-list.
[^] # Re: Ben voyons
Posté par Cédric Blancher . En réponse au journal J'en ai marre de Google !!. Évalué à 6.
On ne peut pas demander à Google de ralentir sa fourniture de service pour "laisser de la place aux autres". C'est d'une part aux concurrent qu'il appartient de fournir des services de qualité, et d'autre part aux utilisateurs qu'il appartient d'utiliser ces derniers.
Chez Google, j'utilise les moteurs de recherche et parfois Google Maps, parce que je les trouve encore au dessus de ce que proposent les autres.
[^] # Re: Manque les Rump session
Posté par Cédric Blancher . En réponse à la dépêche SSTIC 2006. Évalué à 2.