18 jours après la version 0.1 présentée dans une dépèche précédente, voici venir une nouvelle version de LUTIm !
Pour rappel, LUTIm (à prononcer comme lutin) est un service web d'hébergement d'images, gratuit, libre et anonyme. Il est écrit en Perl, est utilisable avec ou sans JavaScript et possède une API, permettant son usage depuis d'autres logiciels comme par exemple Shutter, un logiciel de capture d'écran (rappelons qu'une des principales raisons du développement initial de LUTIm est le partage simple de captures d'écran).
Les trolls discussions ont été âpres sur certains aspects de LUTIm mais fort enrichissantes, aidant LUTIm à évoluer pour le meilleur (tout du moins, je l'espère).
Les changements ont été nombreux, comme en témoigne le Changelog mais les deux principaux changements, vraiment visibles de tout un chacun sont la possibilité de chiffrer les images et les miniatures des images dans la réponse.
L'instance officielle, https://lut.im, bénéficie bien évidemment des derniers développements, éventuellement avant les releases officielles quand il s'agit de bugs graves.
Sommaire
Les nouveautés
Chiffrement
Pour avoir un service d'hébergement d'images garantissant la vie privée, outre la question des logs, il y a la question de qui peut voir ce que l'on a déposé et bien souvent les administrateurs des services le peuvent (All your base are belong to us comme dit le dicton). C'est pourquoi LUTIm propose désormais la possibilité de chiffrer ses images (l'administrateur peut forcer l'usage systèmatique du chiffrement).
À propos du chiffrement, deux écoles s'opposent : le chiffrement côté serveur ou côté client. Chacune d'entre elles possède des avantages et inconvénients dont voici les principaux :
- côté client, le JavaScript est obligatoire, mais le serveur ne peut pas connaître la clé ;
- côté serveur, il faut faire confiance au serveur pour ne pas stocker la clé, mais l'interface peut se passer de JavaScript.
LUTIm utilise un chiffrement côté serveur pour plusieurs raisons :
- LUTIm est codé de façon à être utilisable même sans JavaScript. Cela n'a pas toujours été simple, mais c'est un point essentiel de ce logiciel, donc renoncer à cette fonctionnalité était exclu ;
- les images déposées sur LUTIm sont utilisables directement : vous pouvez déposer des images sur LUTIm et les inclure sur LinuxFR comme c'est le cas dans cette dépèche. Un chiffrement JavaScript aurait empêché une telle utilisation ;
- Le développeur principal (moi :p) préfère de loin le Perl au JavaScript.
L'algorithme de chiffrement est Blowfish et les clés sont générées aléatoirement par le serveur. Les clés font 8 caractères de long et les caractères sont choisis dans [a-zA-Z0-9], ce qui représente 2 821 109 907 456 combinaisons possibles. La longueur de la clé sera paramètrable (par l'admin) dans un futur proche.
La clé n'est bien évidemment jamais stockée sur le serveur, de même que l'image non chiffrée. Elles ne font que transiter en mémoire le temps du chiffrement pour l'image et jusqu'à l'affichage de la réponse pour la clé.
L'instance officielle chiffre désormais systématiquement toutes les images (les anciennes images non chiffrées étant toujours accessibles).
Et si vous avez toujours peur d'un serveur malveillant, installez votre propre instance, c'est si simple :)
Miniatures
Un des reproches gentiment fait à LUTIm était qu'il était difficile de savoir à quelle image correspondait telle URL lors de l'envoi simultané de plusieurs images. Si le module Perl Image::Magick est installé, une miniature de l'image est générée (avant un éventuel chiffrement) et renvoyée encodée en base64, prête à être utilisée en tant que source dans une balise img. L'absence d'Image::Magick ne pose aucun problème à LUTIm qui fonctionnera normalement, juste sans les miniatures.
L'encodage en base64 permet de ne pas garder la miniature sur disque pour garantir la confidentialité de l'image (si l'image est chiffrée et pas la miniature, quel intérêt ?) ainsi que pour éviter l'encombrement de l'espace disque.
La création de la miniature et son encodage en base64 ne nécessitent à aucun moment d'enregistrer l'image dans un fichier.
Statistiques
Stocker les images des autres est fort gentil, mais il est bon de garder un œil sur l'évolution du service. Aussi une page de statistiques a fait son apparition. Si elle ne fournit pas la taille du répertoire des fichiers, elle permet toutefois d'appréhender d'un coup d'œil le nombre total d'images déposées, le nombre d'images déposées par jour et l'évolution du nombre total d'images.
La période de statistiques est paramètrable par l'administrateur et il faut mettre en place une tâche cron pour générer les statistiques.
Si le JavaScript n'est pas activé, l'utilisateur verra apparaître un tableau des données utilisées pour la génération des graphiques.
Les graphiques sont générées avec le plugin jquery SimpleGraph et la bibliothèque Raphael mais d'autres modules sont actuellement à l'étude.
Vous pouvez voir les graphiques de l'instance officielle.
Tâches cron
Outre la génération des statistiques, d'autres actions peuvent être activées via cron :
- suppression des IPs des envoyeurs dans la base de données après un délai paramètrable ;
- suppression des images expirées (les images étaient auparavant supprimées lors d'une tentative d'accès) ;
- surveillance de la taille du répertoire des images avec 3 actions possibles si la taille maximale configurée est dépassée :
- émission d'un message sur la sortie standard (cron enverra ce message par mail) ;
- création d'un fichier bloquant tout nouvel envoi d'images (avec avertissement aux utilisateurs. Le fichier est supprimé si on repasse sous la limite lors de l'exécution de la tâche) et émission d'un message ;
- suppression des images les plus anciennes par paquet de 50 jusqu'à avoir une taille de répertoire en dessous de la limite et émission d'un message (non recommandé) ;
Autres ajouts
Un peu en vrac, voici d'autres nouvelles fonctionnalités :
- possibilité de diffuser un message sur les pages d'accueil, d'informations et de statistiques ;
- possibilité de bloquer manuellement l'envoi d'images en créant un fichier spécifique à la racine du répertoire de LUTIm (ce n'est pas le même fichier que celui posé par la tâche cron de surveillance du dossier d'images) ;
- meilleure détection des types MIME ;
- barre de progression des envois d'images ;
- autorisation de requêtes cross-domain (la liste des domaines autorisés est configurable ou désactivable) ;
- documentation de l'API (celle-ci doit encore être mise à jour, mais l'essentiel est décrit) ;
- Ajout d'en-têtes HTTP pour les images en cohérence avec leur durée de vie ;
- possibilité d'envoi d'images en donnant leur URL. L'image est alors téléchargée sur le serveur.
Le futur
Si LUTIm est jeune, il n'en a pas moins déjà démontré sa robustesse face à l'effet Korben (le pic de plus de 2 000 images envoyées sur la page des statistiques) et les retours sont encourageants, que ce soit par les utilisateurs, par les administrateurs désireux d'installer leur propre instance, ou par la communauté Perl francophone (coucou les Mongueurs) voire anglophone (via la liste de diffusion du framework Mojolicious).
Le développement de LUTIm ne s'arrêtera donc pas là. Des demandes de fonctionnalités sont toujours en attente sur github et il ne tient qu'à vous d'en ajouter d'autres !
Entre autres choses, la priorité de la version 0.3 sera l'écriture de tests (non, il n'y a pas encore de suite de tests, et c'est mal, je sais) ainsi que l'ajout de la possibilité d'utiliser une base MongoDB plutôt que SQLite (ça sera une possibilité, pas une obligation, SQLite sera toujours supporté).
Divers
L'instance officielle est disponible en connexion sécurisée, avec un vrai certificat, permettant d'embarquer les images provenant de LUTIm sans soulever le problème de Mixed Content.
LUTIm est disponible en français et en anglais. Le choix de la langue est fait par les préférences de langue du navigateur (en-tête HTTP Accept-Language). Si vous voulez proposer une nouvelle langue, toutes les contributions sont les bienvenues ! Voir ici pour les fichiers de langue.
La concurrence est là (https://img.bi/, libre et écrit en node.js.) mais un LUTIm sait se montrer courageux et résister à l'adversité !
Maintenant que le chiffrement est de la partie, le petit frère de LUTIm, Lufi pourrait faire son apparition relativement vite. Lufi sera un service d'hébergement de fichiers basé sur ±90% du code de LUTIm.
Vous pouvez soutenir LUTIm avec flattr, bitcoin (1K3n4MXNRSMHk28oTfXEvDunWFthePvd8v) ou encore dogecoin (DFDpahcHFBf2rGMGe49H7m3USw6JMhmwGo).
Vous pouvez aussi simplement parler de LUTIm autour de vous et utiliser le hashtag #Lutim lorsque vous en parlez sur les réseaux (a)sociaux.
Aller plus loin
- Instance officielle de LUTIm (395 clics)
- Page github du projet (90 clics)
- Liste des changements (25 clics)
- Shutter (61 clics)
- La page de statistiques de l'instance officielle de LUTIm (59 clics)
# Félicitations
Posté par Finwë . Évalué à 2.
Beaucoup d'améliorations en peu de temps !
Pour ma part j'avais utilisé la v1 que j'avais trouvé simple et rapide mais du coup c'est encore mieux :)
Bonne continuation.
[^] # Re: Félicitations
Posté par Framasky (site web personnel) . Évalué à 4.
Thx ;-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Chiffrement
Posté par fridim . Évalué à 1.
Est-ce que tu peux détailler cette partie :
La clé est sur le serveur ou pas ?
Pour moi elle est bien quelque part, si elle n'est pas côté client, elle est côté serveur.
L'admin malveillant pourra trouver la clef d'une image ou est-ce qu'il y a un mechanisme particulier de protection ?
Pour ceux qui se pose la question, d'après http://calc.opensecurityresearch.com/, pour brute-forcer une clef de 64 bits en blowfish, c'est :
sur un 3.4GHz Intel Core i7-2600K
[^] # Re: Chiffrement
Posté par Framasky (site web personnel) . Évalué à 6.
Oui je veux bien détailler :-)
La clé est effectivement sur le serveur mais n'est jamais enregistrée, que ce soit en bdd, dans les logs ou je ne sais quoi. Elle est générée, utilisée, transmise puis oubliée.
L'admin malveillant fera donc ce qu'il voudra (je me pose la question d'une demande judiciaire : on m'oblige par voie légale à garder les clés mais comme c'est de l'AGPL, je dois donner le code qui tourne, donc avec la modif enregistrant la clé. La loi pourrait-elle m'empêcher de releaser ? Sans doute que oui.).
Bien évidemment, il est conseillé, si on utilise le chiffrement, d'utiliser une connexion sécurisée (il faudra d'ailleurs que je mette un redirect 301 de http://lut.im vers https://lut.im).
Ceci dit, je ne pense pas que le chiffrement JavaScript empêche réellement l'admin malveillant de récupérer la clé. Il est bien possible d'ajouter la clé à l'envoi du fichier ou de la planquer chiffrée dans un cookie. Le seul avantage du JavaScript, c'est qu'on peut lire le code exécuté, mais avec le js minifié :s
Bref, pour ce genre de service, le mieux est toujours d'héberger sa propre instance :-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
[^] # Re: Chiffrement
Posté par cjlano . Évalué à 1.
Salut!
Il me semble que l’intérêt principal de ne pas envoyer la clé au serveur, ce n'est pas tant la confiance dans l'admin du site, mais plutôt l'interception de la clé sur le réseau. La clé est apparemment mentionnée dans l'URL qui est envoyée au serveur, donc tous les routeurs intermédiaires peuvent la récupérer…
C'est pour cela que ZeroBin chiffre dans le navigateur. Mais bien sûr, cela nécessite javascript.
Ou alors j'ai mal compris un truc?
[^] # Re: Chiffrement
Posté par jyes . Évalué à 4. Dernière modification le 11 mars 2014 à 11:06.
Si tu chiffres la connexion vers Lut.im alors les routeurs ne verront pas l’URL (ils ne verront que le nom du serveur contacté). L’intérêt de ne pas envoyer la clé au serveur, c’est que même l’administrateur de ce serveur (ou la NSA qui en aurait pris possession) n’aura pas la clé (avec le chiffrement côté navigateur, elle est même contenue dans une partie de l’URL qui n’est pas envoyée au serveur).
[^] # Re: Chiffrement
Posté par J'informatique (site web personnel) . Évalué à 1.
Je suis content de voir la fonctionnalité chiffrement ajouté à LUTIm. C'était un prérequis pour moi pour pouvoir utiliser ce service. Je pense qu'en terme de brute-force de clé avec la puissance de calcul des réseaux distribués de la NSA, la clé doit être trouvé en quelques jours. Comment pourrais-t-on améliorer la sécurité, existe-t-il d'autres algos de chiffrement facile à mettre en œuvre et qui tiennent plus longtemps ?
En tout cas, c'est déjà beaucoup mieux que de n'avoir pas de chiffrement du tout ! Et pour ça un grand merci au développeur du projet.
# Clap clap le lutin
Posté par Anonyme . Évalué à 0.
LUTim, pardon :)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.