Last entries

Wed 10 Oct 2012

  • David Mentré

Cachez votre utilisation du web, utilisez HTTPS Everywhere

Vous le savez certainement, mais la quasi-totalité du temps, quand vous surfez sur le web, toutes les informations que vous envoyez ou recevez du site web que vous consultez sont consultables par quiconque entre ce serveur et vous. Ce quiconque peut être votre employeur, votre fournisseur d'accès, etc. Il a cependant un moyen de cacher ces informations en utilisant le protocole HTTPS, le "S" étant pour "Sécurisé" par rapport au protocole HTTP que vous utilisez par défaut.

Le problème ? La plupart des sites web, même s'ils offrent un accès en HTTPS à leur site, cachent son utilisation sous le tapis. Tous les parties du site ne sont pas en HTTPS ou vous démarrez en HTTPS mais revenez immédiatement en HTTP standard. C'est là qu'intervient l'extension pour Firefox HTTPS Everywhere développée par l'EFF (Electronic Frontier Foundation), association américaine de défense des droits dans le monde numérique. Cette petite extension possède une petite base de règles qui permet d'utiliser HTTPS dès que c'est possible et notamment sur la plupart des sites courants (Facebook, Google, etc.).

L'installation de cette extension est triviale et elle vous apporte un petit supplément de vie privée. N'attendez pas !

Tue 21 Aug 2012

  • David Mentré

bentobako.org utilise DNSSEC

J'ai activé DNSSEC sur mon domaine, bentobako.org (qui entre autres héberge ce blog). J'ai utilisé pour ce faire la documentation d'OVH (pas vraiment difficile : un clic à faire dans le managerv3 puis attendre 24h).

Évidemment, ça ne sert pas à grand chose : le DNS de mon fournisseur d'accès (Numericable) ne valide pas DNSSEC et installer un résolveur comme bind9 ou unbound en local ne marche pas sur ma Ubuntu (conflit pour utiliser un port réseau, je n'ai pas vraiment cherché à comprendre ce qui ne marche pas).

Pour vérifier les adresses DNSSEC, j'utilise le plugin DNS Validator dans Firefox. Amusant de voir que ni www.google.fr ni www.ovh.com n'utilisent DNSSEC. On n'est pas prêt de sécuriser tout ça ! :-)

Thu 09 Apr 2009

  • David Mentré

Un générateur de mots de passe aléatoires en ligne

On a souvent besoin de générer des mots de passe aléatoires pour un nouveau compte sur un site web, mettre à disposition des photos ou chiffrer une archive. Habituellement, j'utilise un petit programme libre en C, dev-random-pass-gen.c, mais cela nécessite d'avoir une machine Linux à disposition avec le programme disponible, de se connecter dessus et d'exécuter le programme. Donc, comme tout bon informaticien qui se respecte, je suis flemmard et j'ai voulu me faire un petit service en ligne sur un serveur web qui me fournit ces mots de passe pour n'avoir ensuite qu'à les copier/coller. Maintenant, il me suffit d'aller sur https://bentobako.org/newpassword. :-)

Pour réaliser ce service, j'ai procédé en deux étapes :

  1. faire un petit programme C utilisable sous forme de CGI ;
  2. configurer le serveur web pour rendre accessible le CGI à la bonne URL, en HTTPS.

Générateur de mot de passe en CGI

Le générateur de mot de passe proprement dit est un petit programme C utilisable sous forme de CGI, Common Gateway Interface. Un CGI est un programme appelé par le serveur web qui peut lire certains paramètres envoyés par le serveur (URL, valeurs de formulaires, etc.), travaille un peu puis renvoie un document (une page HTML, une image, une redirection, etc.). Concrètement, il faut renvoyer le type de document (par exemple Content-type: text/html), une ligne vide puis le document lui-même (<HTML><HEAD>...) (voir cette documentation pour plus de détails).

Pour ma part, vu que je ne lis aucun paramètre d'entrée, le programme se contente de renvoyer le mot de passe en texte simple :

 Content-type: text/plain
 
 6fimuNfg8GoCEmhCkpPrX1NyELpXWv1iJrR6XHUJDSq

Je suis parti de mon générateur de mots aléatoires précédent, avec trois modifications :

  • lecture de /dev/urandom, non bloquant s'il n'y a pas assez d'entropie, au lieu de /dev/random, bloquant, pour éviter un Dénis de Service sur le serveur : un attaquant pourrait épuiser toute l'entropie du serveur en faisant des demandes répétées de mots de passe ;
  • chaque lettre du mot de passe est un caractère alpha-numérique (A-Z, majuscule et minuscule, et 0-9). Comme je ne compte pas mémoriser les mots de passe produits, ça me donne plus de possibilités, c.-à-d. plus d'entropie ;
  • le mot de passe final fait 43 caractères, ce qui fait une entropie de 256 bits (log2((26+26+10)^43).

Le code résultant est disponible à l'URL http://www.linux-france.org/~dmentre/code/dev-random-pass-gen-cgi.c.

Son exécution donne :

$ ./dev-random-pass-gen-cgi 
Content-type: text/plain

6fimuNfg8GoCEmhCkpPrX1NyELpXWv1iJrR6XHUJDSq

Configuration du serveur web

Grosso-modo, il faut configurer le serveur web pour :

  • exécuter le CGI quand on accède à l'URL désirée ;
  • utiliser une URL en HTTPS pour éviter que tout le monde puisse lire le mot de passe en cours de route.

Voici la configuration lighttpd utilisée.

J'ai compilé et copié le programme sur mon serveur web, dans /var/www/ :

# gcc -Wall -o /root/dev-random-pass-gen-cgi \
                          /root/dev-random-pass-gen-cgi.c
# mv /root/dev-random-pass-gen-cgi /var/www/newpassword
# chown www-data:www-data /var/www/newpassword

Ensuite, j'ai configuré un fichier /etc/lighttpd/conf-available/11-redirect-to-https.conf qui fait une redirection en HTTPS de tout accès à l'URL http://bentobako.org/newpassword :

$SERVER["socket"] == ":80" {
  $HTTP["host"] =~ "bentobako.org" {
      url.redirect = ( "^/(newpassword.*)" => "https://bentobako.org/$1"
		     )
  }
}

Il faut ensuite un fichier /etc/lighttpd/conf-available/11-newpassword.conf qui permette l'exécution du programme en CGI uniquement pour l'URL /newpassword (voir la doc de mod_cgi pour plus de détails) :

server.modules  += ( "mod_cgi" )

$HTTP["url"] =~ "^/newpassword" {
    cgi.assign = ( "/newpassword" => "" )
}

Il ne reste plus qu'à activer cette configuration :

# lighttpd-enable-mod redirect-to-https
# lighttpd-enable-mod newpassword
# invoke-rc.d lighttpd restart

Et hop, ça marche ! :-)

Rapide analyse de sécurité

Le programme C ne présente aucun risque de sécurité car :

  • il ne prend aucune entrée venant du navigateur client ;
  • il n'utilise aucune ressource permanente sur le serveur (mémoire, disque) ;
  • il utilise /dev/urandom en mode non bloquant ;
  • il fournit un mot de passe avec 256 bits d'entropie qui est considéré comme largement suffisant pour les besoins actuels.

La configuration du serveur web garantit :

  • qu'un programme ne sera exécuté en CGI que s'il est accédé par l'URL /newpassword ;
  • que le mot de passe est protégé en transit par l'utilisation d'HTTPS qui chiffre le transfert ;
  • qu'on a l'assurance de bien parler à son serveur grâce à HTTPS, pour peu qu'on ait enregistré son certificat dans son navigateur ;
  • qu'on ne peut pas faire d'erreur en accédant en clair au CGI grâce à la redirection obligatoire vers HTTPS.

Vous pouvez utiliser librement mon serveur, mais rien ne vous garantit que j'utilise réellement le programme ci-dessus et que je ne stocke pas tous les mots de passe générés. ;-) Mais vous avez maintenant toutes les informations pour le faire chez vous.

Mon 23 Feb 2009

  • David Mentré
  • 5

Serveurs web haute performance

Une remarque de Jean-Marie m'a rappelé que la plupart des sites web actuels sont vraiment lents (un exemple au hasard ? Voyages-sncf.com bien sûr !) alors que nos machines, disques durs et réseaux sont de plus en plus rapides ! La principale cause, comme d'habitude, c'est que l'on utilise de plus en plus de logiciel dynamique et plus ou moins interprété comme du PHP ou du Python. Mais un composant essentiel de la pile web, c'est quand même le serveur web. Et celui que la plupart des gens utilise, Apache (52% de part de marché en janvier 2009), est il faut le dire une vraie bouse. Heureusement, le monde du Libre est formidable : il y a des alternatives ! \o/

La première alternative, c'est lighttpd (prononcer lighty) et c'est celui que j'utilise sur mon serveur web. Subjectivement, c'est vrai qu'il est rapide. Il se lance ou se relance en un clin d'œil et le fichier de configuration a une syntaxe plutôt agréable. Et objectivement, il est rapide d'après des tests faits par Fred sur deux machines identiques. ;-) Malheureusement, sa documentation est plutôt légère : quand je me pose des questions sérieuses sur un module, par exemple l'ordre d'interprétation des règles de ré-écriture d'URL, je ne trouve pas d'information détaillée. Par contre, comme il est utilisé par beaucoup de gros sites pour leurs parties statiques (YouTube, Wikipédia, ...), on peut supposer qu'il est correctement programmé du point de vue sécurité.

L'autre prétendant, c'est nginx. Pour lui, je n'ai pas trop d'expérience. Il fait un peu fouilli puisqu'il fait, en plus de serveur web, mail proxy server. Et j'ai entendu dire qu'il y avait des bugs et que les développeurs étaient plus intéressés à rajouter de nouvelles fonctionnalités qu'à les corriger : un peu embêtant pour un serveur web accessible à la sauvagerie du Wild Wide Web. Mais bon, ce ne sont que des ouïes dire, à vérifier donc.

Le troisième prétendant, petit nouveau dans l'arène, c'est Cherokee, que j'ai découvert grâce aux notes de version de la toute nouvelle Debian Lenny. :-) Cherokee a l'air très sympa (outre son logo ;-) : configuration par une interface web (sécurisée par mot de passe unique et ssh) mais sauvegardée dans un fichier texte, documentation qui a l'air complète, et toutes les fonctionnalités qu'on peut attendre d'un serveur web moderne : équilibrage de charge, ré-écriture d'URL, support de FastCGI et consorts, serveurs virtuels, etc. Et surtout, il est rapide... enfin d'après leurs propres benchmarks. :-) Mais bon, j'envisage à moyen terme de le tester à la place de lighttpd.

Enfin, mon outsider, c'est Ocsigen. Plus qu'un serveur web, c'est un environnement de développement complet, en OCaml, qui est intégré au serveur web. Et depuis la dernière version 3.11 du compilateur OCaml qui permet de charger des modules de code natif dans un programme OCaml, Ocsigen fonctionne en code natif ! Cela veut dire que l'on a un environnement de développement web avec toutes les bonnes propriétés d'OCaml (typage fort à la compilation, y compris sur des requêtes SQL de PostgreSQL, garbage collector performant, beaucoup de bibliothèques, ...) et qui en plus produit du code natif, donc réellement efficace (comme le montre ces tests de Dario Teixeira). Cela me semble la meilleur combinaison pour faire des sites web qui poussent ! Évidemment, il faut programmer en OCaml et surtout se faire à l'environnement d'Ocsigen, ce qui n'est pas aussi simple qu'en PHP par exemple. Mais même en tant que simple serveur web de pages statiques, Ocsigen se compare correctement à lighttpd et Apache, sans toutefois être aussi performant. Et bien sûr, pour les sites dynamiques, il est nettement plus rapide que Ruby (qui certes n'est pas le langage le plus rapide) !

Face à Apache, tous ces serveurs web ont beaucoup d'avantages mais un gros inconvénient : les logiciels web sont tous conçus pour Apache. Donc il faut souvent adapter la configuration du serveur web, notamment dans la gestion des droits d'accès (configuration équivalente aux .htaccess). Rien de bien mortel, mais c'est toujours du travail en plus et on a toujours le risque de faire une erreur.

En tout cas, une chose est sûre, la liberté et la dynamique du Libre nous permet d'avoir des solutions réellement innovantes. Il ne vous reste plus qu'à les utiliser. ;-)

Mon 16 Feb 2009

  • David Mentré
  • 2

Blogs intéressants pour faire des sites webs

Quelques blogs que je suis régulièrement autour du thème du web, pour faire des sites web, etc. :

  • A list apart : des articles de fond sur le web, de niveaux bien sûr inégaux mais il y a toujours quelque chose d'intéressant à lire sur la durée ;
  • Free Tools : malgré son nom, blog en Français sur les outils, bibliothèques, etc. pour enrichir un site web. Beaucoup de trucs en JavaScript. L'auteur ne fait pas attention aux licences et c'est toujours gratuit mais en pratique c'est très souvent du vrai Libre ;
  • Usability Post : des réflexions sur les interfaces utilisateur. Ne concerne pas uniquement le web. Des réflexions parfois intéressantes, parfois plus futiles ;
  • Chromium Blog : blog qui concerne le cœur Open Source du navigateur Google Chrome. Bien que cela concerne les évolutions du logiciel, il y a des billets intéressants sur les choix de sécurité, les problèmes de compatibilité, les choix d'interface utilisateur, etc.
  • Planet OSM.fr : l'aggrégation des blogs des OSM-mappeurs français. Les billets de Xavier sont toujours très intéressants pour suivre l'actualité d'OSM, les billets intéressants à lire sur le sujet, etc.
  • Smashing Magazine : un blog sur le design de site web, les dernières tendances du moment (voir les billets de fin 2008 - début 2009 à ce sujet), et pleins de jolies images. Du contenu gratuit mais malheureusement bien souvent pas libre.
  • Technologies du Langage de Jean Véronis : Jean Véronis est un professeur de linguistique et d'informatique et fait beaucoup de billets autour de l'analyse des discours (hommes ou femmes politiques), des blogs (il travaille beaucoup avec Wikio maintenant), etc. Il y a du contenu mais ça reste pédagogique.

Mon 26 Jan 2009

  • David Mentré
  • 2

Internet change-t-il notre façon de lire ?

Je suis récemment tombé (après tout le monde apparemment ;-) sur cet article : Internet et Google vont-ils finir par nous abrutir ?

Je ne partage pas le pessimisme de l'auteur mais je suis d'accord avec son constat : Internet change ma façon de lire. J'ai plus de plus de mal à lire un article ou document un peu long de bout en bout, que ce soit sur papier ou sur Internet. Je survole maintenant les articles, en essayant de repérer les portions importantes et de manière non linéaire. Pour lire un livre, je dois maintenant éteindre l'ordinateur.

C'est parfois inquiétant. Mais sommes nous plus stupides ou modifions nous notre comportement intellectuel ?