Blog Jaune

La nouvelle version de Ubuntu Netbook Remix (10.04) intégre quelques modifications au niveau du tableau de bord en haut de l'écran.
Il n'est plus possible de le personnaliser, tout est figé. Ce choix me semble étrange, mais je ne vais pas abandonner tout les avantages de cette version à cause de cette limitation.

La solution consiste à aller trifouiller dans le système un fichier en xml. C'est pratique :-)

Le fichier /var/lib/gconf/une.mandatory/%gconf-tree.xml est donc à modifier, en root.

J'ai mis la section panel en commentaire . Mais on pourrais aussi le supprimer, une fois les réglages spécifiques à netbook remix appliqués à l'aide de l'outil gconf-editor.

Après avoir relancé la session (la flemme de relancer gconf et gnome-panel), tout redevient comme avant.

Le web est basé sur le protocole HTTP, protocole client-serveur qui a une communication entre le client et le serveur en deux étapes. Le client après avoir ouvert une connexion fiable, fait une requête sur une ressource caractérisée par une URL, et le serveur renvoi le résultat correspondant, et ferme ensuite la connexion.

Le protocole est assez simple à comprendre, et sa forme textuelle facilite beaucoup la compréhension. Voici un exemple très simple:

GET /index.html

Réponse du serveur

Ce principe de conception n'est pas adapté aux applications en temps réel, car bien trop lourd pour leurs utilisations du réseau.

Par exemple, pour un client IRC (chat en ligne) sur le web, il n'est pas possible d'avoir les messages qui arrivent en continu.

Cependant, la version 1.1 de HTTP propose de ne plus fermer automatiquement la connexion après chaque requête, pour accélérer la navigation sur le web. Cette fonctionnalité s'appelle le keep-alive.

Une astuce classique est donc de faire pleins de requêtes HTTP à la suite qui sont en attente des messages. Quand un message arrive, le serveur écrit le message dans le flux, termine la requête, et passe à la requête suivante. Cela permet en une seule connexion d'avoir un temps réel plus ou moins précis. Car le protocole HTTP est assez lourd en contenu.

Mais même avec cette astuce, il est impossible d'écrire et de lire dans la même connexion. Pour des jeux en réseau, il faudrait ouvrir de nombreuses requêtes en même temps. De plus, utiliser des astuces de ce type n'est pas vraiment beau.

Bref, le protocole HTTP n'est pas du tout adapté au applications en temps réel, et il fallait trouver une solution.

Une solution simple et efficace aurait été de fournir une API TCP et UDP dans les navigateurs webs, mais ces derniers sont très liés au protocole HTTP, et ils ne peuvent descendre les couches du modèle OSI pour toucher au transport des données. HTTP faisant parti de la couche application, le protocole n'a pas à savoir ce qui tourne en dessous de lui, et le navigateur ne peut ainsi donc pas utiliser directement TCP ou UDP.

C'est là qu'arrive WebSockets, qui est une couche de transport au dessus de HTTP, tout ça dans un navigateur web. Son fonctionnement est cependant assez étrange, par son implémentation au dessus du protocole HTTP, ce dernier étant dans la couche application. On a donc une petite incohérence au niveau de la pile de protocoles du modèle OSI. Il y a une couche transport au dessus d'une couche application. D'où la mise en abîme dans le titre.

WebSocket possède une api en javascript de bonne qualité, et son utilisation pourrait exploser dans les temps à venir.

Il est possible de s'amuser avec dans les dernières version de WebKit, en attendant une possible implémentation dans les autres navigateurs webs. La guerre des navigateurs webs étant de nouveau d'actualité.

Malgré tout, le protocole s'éloigne beaucoup de HTTP, en abandonnant le texte pour des codes contenus dans des octets, et cassant la comptabilité avec les serveurs webs. Car l'écriture par le client durant l'envoi des réponses par le serveur change beaucoup le fonctionnement d'un serveur web. Les serveurs mandataires webs sont eux aussi touchés, et il semblerait que si certains arrivent à gérer le fait que le client puisse écrire durant la réponse du serveur, d'autres n'aiment pas du tout cette éventualité.

L'arrivée sur le web ne peut donc pas se faire d'un coup, et il existera toujours des problèmes avec les vieux logiciels, ou le vieux matériel.

C'est un bon essai, mais ce n'est toujours pas demain que l'on pourra avoir un bon client IRC sans hacks pas beaux dans un navigateur web.

Sources:

• HTTP sur wIkipedia
• WebSockets sur wikipedia (en)

Ça trainait dans le disque dur, autant que ça traine aussi sur le blog.

Les BBox de bouygues télécom sont fabriquées par Thomson, et elles possèdent en commun avec de nombreux modèles de l'entreprise une particularité intéressante. C'est à dire qu'il est possible de retrouver sans trop de calculs la clef wpa de la box à partir de son essid.

Si votre réseau wifi a son essid (identifiant du réseau sans fils) sous la forme Nom-426B7F, et que vous avez laissez la clef wpa par défaut, il y a de grande chance que le clef wpa soit retrouvable très rapidement.

Cela veut dire que votre réseau sans fils peut facilement être crackable en quelques secondes. Et avec les nouvelles lois sur internet, c'est vous qui êtes responsable de la sécurité de votre réseau.

Techniquement, la génération de la clef et de l'identifiant se base sur le numéro de série. Il lui est enlevé quelques informations, il passe en hexadécimal, et ensuite à la moulinette (somme de hashage) sha1. Les 10 premiers nombres sont la clef wpa, les 6 derniers, l'essid.

Pour jouer son débutant «script kiddie», il existe une application qui permet de retrouver ça facilement. Sinon, on peut le coder, ce n'est pas très compliqué non plus, mais pas vraiment intéressant.

L'algorithme est vraiment très simple à réaliser. Cela consiste à passer en revue tout les numéros de série possibles, calculer la somme de contrôle sha1, et si la fin correspond à l'essid passé en paramètre, on affiche une clef potentielle.

Donc, évidemment certains en profitent pour vendre des outils, mais autant utiliser ce qui est gratuit (à défaut d'être libre). stkeys est un code source (si vous n'êtes pas capable de le compiler, vous ne méritez pas de cracker votre box) en c++.

Voila, vous avez toutes les informations pour cracker votre box, et pas celle de votre voisin, car ce n'est pas bien. Pour ma part, je suis chez free, et je ne connais personne chez bouygues, mais je ne peut que conseiller si il me vient l'occasion de changer la configuration du réseau wifi.

À ce sujet, l'interface d'administration est pas mal. Elle se trouve à cette adresse: http://192.168.1.254 , et le désormais classique admin en identifiant et admin en mot de passe est utilisé. On peut y voir toutes les machines connectées sur le réseau, à savoir leur adresse ip, leur nom communiqué par le client dhcp, et leur adresse mac.