le lundi 27 octobre

La gnangnantitude

Bon, je crois que samedi dernier, j'ai atteins des sommets de gnangnantitude avec Sylvain. Ça doit être ça, être amoureux... :-$ [1]

Notes

[1] Putain, je fais même des émoticones, enfin des binettes, enfin bref, je fais même des smileys gnangnan sur mon blog !

le lundi 13 octobre

Des nouvelles du front

Bon, ça fait longtemps que je ne suis pas venu ici. Et pourtant il s'est passé plein de trucs depuis, oula, plus d'un mois...

Déjà, j'ai une petite boule de poils qui saute partout et qui joue avec ma prise USB, avec la souris, et tout ce qui traine sur le bureau (c'est donc officiellement la catastrophe). Et ça marche sur le clavier... Bon, je ne sais toujours pas comment l'appeler. Oula, elle a bien failli m'envoyer bouller... bon, c'est fait, toutes les facturettes Total sont tombées par terre... Bon, maintenant, elle joue avec la panthère en peluche. Bon, je disais, après une semaine, je ne sais toujours pas que nom lui donner. Cela dit, ça ne la gène pas beaucoup.

La nouvelle suivante, c'est que ya qqch dans les threads qt4 qui ont changés, et maintenant, ça fait boum quand je lance mon programme fait maison de téléchargement de photos. En gros, ça veux dire que tant que je n'aurai pas corrigé, toutes les photos resteront dans l'appareil. Et ça me fait un peu chier de reposer les yeux sur du code qui est quand même un peu cracra, il faut bien le dire.

Bon, un crash systeme plus tard (ma machine est en fin de vie, là...), et me revoila pour parler des autres sujets :

  • cyberrail, ça avance, je me dirige vers un dokuwiki + svn. Je pense que ça devrait aller pour commencer.
  • j'ai commencé à écrire un petit truc dont je parlerais ensuite
  • et plein d'autres trucs insignifiant dont je ne vais pas parler...

Voila pour tout de suite. Je dois dire que les crashs à répétition me coupent un peu dans mon inspiration...

le vendredi 22 août

Secure Socket Layer

Après avoir joué avec Apache, je me suis intéressé à un autre sujet : SSL. C'est d'ailleurs ce qui m'a prit le plus clair de mon temps. Pour faire fonctionner SSL avec Apache, en faisant tout bien dans les règles de l'art, il faut bien comprendre le fonctionnement de SSL et de ses certificats.

SSL fonctionne avec la notions de tiers de confiance. Un tiers de confiance est une entité reconnue plus ou moins universellement qui certifie l'identité, et donc les certificats qu'on lui présente. On peut citer plusieurs entités comme Thawte ou Verisign pour les connus et les plus chers (et espérons le, les plus sérieuses dans leurs opérations de vérification). Ensuite, pleins d'autres entreprises se sont vue accréditées par les deux premiers cités pour également délivrer des certificats.

Les certificats de ces autorités de certifications sont publics. Par courtoisie, les éditeurs de navigateurs livrent ceux-ci préchargés avec les certificats des autorités de confiances les plus connues. Vous pouvez bien sur rajouter tous les certificats d'autorités de confiance que vous le souhaitez. Par exemple, j'ai pour ma part importé les certificats de CACert.org, qui propose des certificats gratuits basés sur un système de vérification automatisé.

Attention, ajouter un certificat, c'est accorder sa confiance complète à l'organisme sur tous les certificats qu'il pourrait accorder par la suite, et sur tout ceux qu'il a déjà accordé. Ce n'est donc pas une décision à prendre à la légère. C'est une opération qui n'est pas naturelle, aussi, il ne faut le faire qu'une fois que l'on a compris toutes les implications que cela entraîne.

En effet, l'autorité de certification va le plus souvent vérifier que les informations contenues dans un certificat sont bien celles qui sont alléguées. Un certificat peut contenir les informations suivantes :

  • le CN, common name, est l'information technique qui permettra au navigateur de s'assurer que le certificat proposé correspond bien à l'url entrée. Il s'agit du nom de domaine.
  • le pays
  • l'État
  • le nom de l'organisation
  • l'email

Dans le cas de CACert, le système ne vérifie que le nom de domaine (pour le cas le plus simple), et toutes les autres informations sont effacées du certificat.

La question qui vient à l'esprit, c'est : pourquoi vérifier qu'on parle bien au bon serveur puisqu'on a rentré son adresse dans sa barre d'adresse ? En effet, à moins que les serveurs DNS soient corrompus (risque qu'on ne peut pas exclure), la connexion se fera toujours avec le bon serveur.

Et bien, ce n'est pas aussi simple : d'une part, un serveur DNS est un serveur sur lequel vous n'avez pas forcement la main. Et il s'agit d'un tiers qui n'est pas forcement fiable. Celui de votre entreprise peut vous retourner sur l'adresse d'un proxy transparent, ou tout autre serveur. D'autre part, HTTP a été conçu pour fonctionner via des proxy qui peuvent très bien modifier ou générer les informations sans passer par le serveur auquel vous pensez vous connecter. La vérification du certificat prouve que vous vous adressez bien au serveur que souhaitez joindre, et non pas à un quelconque intermédiaire.

Mais dans ce cas, pourquoi une autorité de confiance ? Cette autorité va vérifier (par courrier, téléphone, huissier ou tout autre méthode qui lui semble pertinente) que les données contenues dans le certificat sont bien celles correspondant au propriétaire. Ainsi, Verisign vérifiera que FNAC SA, propriétaire du certificat (vous pouvez aller vérifier) est bien un nom que peut utiliser la Fnac pour son site web. Il est d'ailleurs amusant de constater que ce certificat n'utilise pas le wildcard * dans son certificat et que donc https://fnac.com ne fonctionne pas, alors que https://www.fnac.com, lui fonctionne.

Le wildcard, qu'est ce que c'est ?

Comme on a pu le constater, le certificat embarque le nom de domaine auquel il est associé. Ainsi, un certificat plo.org ne peut pas fonctionner chez bla.com. Mais c'est plus sévère que ça : un certificat www.fnac.com ne peut pas fonctionner pour fnac.com ! Cela introduit une certaine rigidité dans le système puisqu'il faut un certificat pour chaque domaine et sous domaine que l'on doit administrer. La réponse est venu de certificats wildcards, qui permettent de mettre une étoile * à la place d'un des éléments de l'url, pour que par exemple ftp.fnac.com et www.fnac.com puissent fonctionner avec le même certificat SSL qui contient *.fnac.com. Les wildcard sont très cher et difficile à obtenir auprès de Verisign ou Thawte. Vous pouvez par contre en obtenir un auprès de CACert. Malheureusement, le certificat racine de CACert n'est pas tout le temps inclus dans les navigateurs.

Est ce qu'on peut créer un certificat * ?

Oui, on peut, mais aucune autorité de confiance ne vous le signera. Tout simplement parce que vous ne pourrez jamais justifier de la propriété de tous les domaines. De plus, il vous drait des certificats comme *.*.* si vous voulez un certificat pour www.plop.org.

Et techniquement, comment ça marche ?

Du coté de l'autorité de certification (c'est à dire probablement jamais vous), c'est simple, elle se créé un certificat qu'elle signe elle même. C'est un certificat auto-signé. Sa valeur ne provient que parce qu'il est inclus dans tous les navigateurs. Ainsi, même si vous créez votre propre certificat, il a très peu de chance d'être inclus d'office dans un quelconque navigateur. Vous devrez donc demander à vos utilisateur de l'ajouter eux même, et peu seront enclin à le faire, d'autant plus qu'ils ne connaissent pas votre sérieux. La création d'un certificat passe par la création d'une paire de clé privée / publique.

   # génération d'une paire de clés
   openssl genrsa -aes256 -out privkey.pem
   
   # génération d'un certificat auto-signé 
   openssl req -new -x509 -key privkey.pem -out cert.pem

Attention, le fichier privkey.pem ne doit jamais être rendu publique. Sa seule utilisation sera pour la signature future de certificat. Donc, en gros, ce fichier ne bougera pas de machine.

Par contre, le fichier cert.pem est un fichier publique. Vous pouvez (ou pas) le diffuser librement. C'est ce fichier que vos utilisateurs doivent importer dans leurs navigateurs. Suivant leur modèle, cela fonctionnera tout de suite ou cela nécessitera une conversion du format PEM au format DER pour les saveurs Redmond. En tout cas, ce fichier ne contient rien de privé. Par contre, il est inutile de chercher à le modifier, il serait rendu inutilisable.

Attention encore, vous ne pourrez plus rien signer si vous perdez le certificat ou la clé.

Du coté de l'éditeur du serveur SSL (donc peut-être vous un jour), c'est légèrement plus compliqué, vous devez créer une paire de clés comme décrit précédemment (avec les mêmes réserves), ainsi qu'une demande de certificat (en effet un certificat est toujours signé, c'est la définition d'un certificat). Une fois votre demande créé, vous devez l'envoyer à une autorité quelconque pour signature. La procédure est en général un copier coller vers le site de l'autorité de certification (dont vous aurez constaté que le site est sécurisé, mais ce n'est pas indispensable). Une fois signé, vous pourrez constater que la signature de cette demande correspond à l'un des certificat préchargé dans votre navigateur.

   # génération d'une paire de clés
   openssl genrsa -aes256 -out privkey.pem
   
   # demande de certificat
   openssl req -new -out demande -key privkey.pem

Là encore, la clé est privée et secrète. La demande est quant à elle publique même s'il n'y a aucun intérêt à la publier.

Pour signer votre certificat, l'autorité va faire plein de paperasse et de vérification et, entre autre, va signer votre demande, qui se muera en certificat :

   # signature d'un certificat avec le certificat de l'autorité
   openssl x509 -CA ./cert.pem -CAkey ./privkey.pem -req -in ../servercert/demande -out ../servercert/servercert.pem -CAcreateserial

C'est à ce moment qu'elle vérifie que les informations contenues dans le certificat sont exactes. Chez CACert, ils ne certifient que le nom de domaine (pour les certificats de serveur http) et l'adresse email (pour les certificats d'adresse email). Pour vérifier un nom de domaine, ils envoient un marqueur aléatoire à l'une des adresses email trouvées dans le whois. Charge à vous d'aller lire les mails de cette adresse et d'y répondre favorablement.

L'autorité de certification doit faire d'autres démarches, comme par exemple tenir à jour une liste de révocation, etc. Le fonctionnement d'une autorité de certification est un sujet complet et je n'en parlerai pas plus maintenant.

Une fois le certificat récupérer, l'exploitation peut commencer. Dans Apache 2, il suffit de rajouter les directives suivantes dans le contexte approprié :

   LoadModule ssl_module         modules/mod_ssl.so
   <IfModule ssl_module>
   SSLRandomSeed startup builtin
   SSLRandomSeed connect builtin
   SSLEngine on
   
   SSLCertificateFile /home/manu/perso/web/runtime/ssl/servercert/servercert.pem
   SSLCertificateKeyFile /home/manu/perso/web/runtime/ssl/servercert/privkey.pem
   </IfModule>

Le serveur pourra ainsi s'authentifier et déchiffrer tout ce qui lui sera renvoyé.

Une dernière chose, tous les certificat possèdent une date limite d'utilisation : un certificat doit donc être renouvellé régulièrement au risque d'avoir une alerte du navigateur. Ainsi les certificats de Verisign expirent entre 2028 et 2036. Par contre, il y a fort à parier que les certificats que vous achèterez chez eux ne seront pas valable plus d'un an...

LAMP

LAMP, c'est quoi ? C'est un acronyme qui veux dire Linux Apache MySQL et PHP. C'est en gros la plateforme la plus courante pour faire tourner des applications en PHP. L'exemple le plus proche est le blog que vous êtes en train de lire. Suite à mon entrée précédente, je suis en train de regarder les différents CMS qui existent afin de choisir quelques chose qui pourrait me seoir [1].

La première étape a été de télécharger les sources d'apache et de les compiler. Réalisé avec les autotools, il ne s'agit que de faire ./configure && make -j 2 && make install

Voici le config.nice qui contient tous les éléments de configuration particulier

   #! /bin/sh
   #
   # Created by configure
   
   "./configure" \
   "--prefix=/home/manu/perso/web/runtime/httpd" \
   "--enable-rewrite=shared" \
   "--enable-ssl=shared" \
   "$@"

Ensuite, il a fallu faire quelques adaptations au fichier de configuration d'Apache : déclarer des alias et inclure certains modules. Rien de bien complexe.

Pour MySQL, j'ai juste fais un apt-get install mysql-qqch. Connaissant déjà un peu Mysql, je n'ai jugé utile de tout faire à la main (en plus, le serveur sert pour d'autres projets).

Vint ensuite le tour de PHP, hop, là aussi téléchargement des sources, ./configure && make -j 2 && make install

le config.nice qui va bien

   #! /bin/sh
   #
   # Created by configure
   
   './configure' \
   '--with-apxs2=/home/manu/perso/web/runtime/httpd/bin/apxs' \
   '--with-mysql' \
   '--prefix=/home/manu/perso/web/runtime/php' \
   '--with-config-file-path=/home/manu/perso/web/runtime' \
   '--with-gd' \
   '--enable-mbstring' \
   "$@"

Il m'a fallu recompiler plusieurs fois PHP et Apache pour y ajouter tous les modules complémentaires dont j'avais besoin. À chaque fois le système génère un fichier config.nice qui contient toutes les options déjà présentes. Cela dit, tant que la compilation ne plante pas, on n'est pas obligé de tout reconstruire. Si cela se passe mal, il suffit de faire un make clean, puis de relancer la compilation (depuis le début, mais ce n'est pas non plus dramatique)

J'ai ensuite essayé (concretement) dotclear 2 et drupal. Dotclear me semble pas mal, rien de transcendant si ce n'est qu'une interface d'extension complète a été prévue. Pour Drupal, c'est un peu plus compliqué, je n'ai pas saisi tous les concepts pour faire fonctionner le site...

Je n'ai pas encore choisi la solution que je vais utiliser, c'est toujours en cours...

Notes

[1] et non pas scier.

le samedi 9 août

Cyberrail, le retour

Je vais faire ici un petit point sur l'état du projet en ce qui concerne le passé et le futur.

Read next

le lundi 21 juillet

Edvige

Ça fait longtemps que je devais en parler ici... La Direction centrale du renseignement intérieur,les nouveaux services secrets français rassemblement douteux des Renseignement généraux et de la Direction de la surveillance du territoire, mets en place le fichier Edvige (http://fr.wikipedia.org/wiki/Fichage_en_France#Fichier_.C2.AB_EDVIGE_.C2.BB). Il s'agit grosso-modo de recenser à peu prêt n'importe quelle information sur un peu n'importe qui sans aucun contrôle. On peut se douter que c'est déjà ce qui se fait en coulisse, mais là, il s'agit d'officialiser une pratique d'un autre temps.

Quelques liens pour prendre la dimension de l'évènement :

Une pétition permet de montrer un minimum votre désaccord avec cette pratique : Pour obtenir l'abandon du fichier Edvige.

le mardi 15 juillet

XIII

3h47 : je termine le dernier volume des aventures de XIII, après avoir lu les 6 précédents.

le lundi 7 juillet

En bref

Alors, comme tout le monde s'en doutait, Miko est mort. Ça a donné lieu à une semaine de laissé aller que je vais devoir rattraper ce soir... Sinon, je vais aller travailler pendant deux mois du coté de Saint-Denis (de l'Île de France).

Pis sinon, rien de bien extraordinaire... À part ce petit truc pour faire perdre du temps : le Desktop Tower Defense

le lundi 30 juin

Miko le chat

Bon, en ce moment, le chat ne va pas bien du tout... Demain, il va voir le vétérinaire, et j'espère que ça va pas être trop grave : ça fait plus d'une semaine qu'il est dans cet état, et comme les consultations chez le vétérinaires sont rares, j'ai pas vraiment pu caser de rendez-vous plus tôt...

le vendredi 27 juin

Le four

Tout à l'heure, mon colloc s'est fait des beignets de poulets. Enfin, s'est fait réchauffé. Sur l'emballage, il y avait la mention "10 minutes au four".

Et bien, résultat, il a mis ses beignets 10 minutes au four à micro-ondes... Le résultat a été immédiat : les beignets sont complètement carbonisés. Le pire, c'est que j'ai moi même, une demi-heure plus tard, oublié mes propres beignets sur le feu... Ils étaient encore mangeable, mais il y avait quand même un arrière goût de brûlé...

le mardi 10 juin

JCVD

Alors, j'ai été voir le dernier van Damme au ciné. Je pensais aller voir un film pas trop mal, et j'ai vu un film finalement assez captivant. Je vais pas m'étendre plus que ça, mais pour ceux qui aiment le personnage de van Damme, ça vaut vraiment le coup.

Par contre, il ne faut pas oublier que c'est une fiction, hein ;-)

Ah, sinon, le site officiel diffuse une bande audio qui mérite un détour pour ceux qui aiment le style.

le jeudi 5 juin

Bon...

J'ai enfin trouvé le temps de faire ce que je devais faire...

Voila le graphique original, sans modifications :

Sinon, j'ai emprunté un câble réseau suffisamment grand à la boîte pour me passer du wifi, et quel plaisir de ne plus avoir de paquets perdu. Quel confort de voir de nouveau les pages arriver rapidement, sans que tout se bloque pour un oui ou pour un non...

le mardi 20 mai

Et voila :-)

Prix du Brent Oil de New York en US$ au 19 mai 2008

Comme je trouvais que les couleurs de bases étaient un peu austères, j'y ai rajouté ma touche personnelle ![1]

Notes

[1] Bon, dans les faits, je trouve ça très moche et les couleurs de bases étaient un peu moins dégueu...

Les prisons, encore

Allez, on continue dans le glauque et l'horreur du système carcéral français : http://www.liberation.fr/actualite/societe/327151.FR.php

Putain, quelle horreur !

le vendredi 9 mai

Le prix du pétrole en euros

On nous bassine tous les jours avec la flambée des prix du pétrole, en nous expliquant que le pétrole bat de nouveaux records chaque jour. Je voulais vérifier si le pétrole augmentait tellement, ou si c'était le dollars faible qui provoquait cette hausse. Voici un petit graphique qui montre le prix du pétrole en dollars et en euros, fait par mes soins :

Évolution du pétrole en euros

On peut remarquer que cette hausse est bien présente, même en euros, mais qu'elle est moins sensible que celle en dollars.