Protéger l’upload de fichier dans Lufi par un mot de passe HTTP
J’envisage de mettre en place une instance de Lufi au boulot pour partager plus facilement des fichiers avec des clients de manière un peu plus élégante que le mail et surtout s’affranchir de certaines limites de taille. Problème, par défaut Lufi ne supporte que l’authentification LDAP pour protéger l’upload, mais pour un seul user, c’est un peu overkill. J’ai donc cherché à mettre en place l’équivalent HTTP, mais il faut s’assurer que les autres liens sont exploitables sans demander de mot de passe. J’ai demandé au développeur pour Nginx, mais je vais vous présenter le résultat aussi pour Apache.
Avant, présentation rapide de Lufi
Lufi est donc un logiciel permettant de partager simplement et de manière sécurisée des fichiers relativement volumineux, typiquement trop gros pour être échangés par mail. Sa particularité, les fichiers sont chiffrés et déchiffrés côté client, et les informations sont enregistrées dans le LocalStorage du navigateur, donc sur un même serveur vous ne voyez que vos fichiers. Et l’administrateur ne peut voir que des blobs. La clé de déchiffrement, elle, est dans l’URL, donc quand on ouvre un lien, on récupère le blob associé, et on le déchiffre après. Ajoutez une couche de HTTPS, et vous avez donc toute la sécurité qu’on peut attendre d’un tel outil en 2016.
Je passerai sur le fait que quand on est pas sous Debian, l’installation peut s’avérer plus rustique (j’ai notamment eu des soucis avec les chemins pour Perl), ça et le theming qui semble compliqué aussi, mais sinon c’est vraiment un logiciel élégant.
Un logiciel un peu trop ouvert
C’est souvent la problématique avec ce genre d’outils, j’en ai trouvé une tetrachiée, très souvent plus mis à jour depuis un bail (j’en ai trouvé un qui convenait très bien, mais qui ne supporte même pas PHP 5.4), ou trop basiques, et pratiquement aucun ne permet facilement d’empêcher l’upload, ou de le filtrer avec une petite couche d’authentification.
Lufi ne fait pas exception à la règle, mais en dehors du Perl qui ne me fait pas particulièrement envie, j’ai trouvé le concept intéressant, le fait qu’il soit utilisé par Framasoft pour framadrop aide pas mal non plus, et cocorico, c’est un frenchie qui développe. Avec la possibilité de se connecter avec son compte Github pour pouvoir poser ses questions sur framagit, aucune raison de ne pas demander de l’aide.
La règle était si simple
Au début, j’ai cherché dans la maigre documentation comment appliquer une couche. Je suis tombé sur le support LDAP, mais vu qu’il ne sera pas beaucoup utilisé, c’était un peu trop de boulot pour le but recherché, sachant qu’on ne peut utiliser notre annuaire que par radius.
J’ai fini par trouver, après avoir été guidé par Luc sur un début de réponse. Pas question de complètement refaire la configuration pour Nginx, seulement l’adapter un peu. On commence par reprendre tout le contenu du bloc location / { (…) } pour le mettre dans un fichier lufi.include :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 |
# Add cache for static files if ($request_uri ~* ^/(img|css|font|js)/) { add_header Expires "Thu, 31 Dec 2037 23:55:55 GMT"; add_header Cache-Control "public, max-age=315360000"; } # HTTPS only header, improves security #add_header Strict-Transport-Security "max-age=15768000"; # Adapt this to your configuration (port, subdirectory (see below)) proxy_pass http://127.0.0.1:8081; # Really important! Lufi uses WebSocket, it won't work without this proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; # If you want to log the remote port of the file senders, you'll need that proxy_set_header X-Remote-Port $remote_port; proxy_set_header X-Forwarded-Proto $scheme; # We expect the downstream servers to redirect to the right hostname, so don't do any rewrites here. proxy_redirect off; |
Il ne reste plus qu’à inclure ce fichier, et par la suite, quand on fait une modification, elle n’est plus à faire qu’à un seul endroit. Pour ajouter le mot de passe pour l’URL racine, qui sert à l’upload de fichiers, voilà ce que ça donne :
1 2 3 4 5 6 7 8 9 10 |
location = / { auth_basic "Acces restreint"; auth_basic_user_file /chemin/vers/.htpasswd; include lufi.include } location / { include lufi.include } |
Par ce moyen, quand on accède à la page d’accueil, qui permet l’upload, on se voit demander un mot de passe HTTP classique, par contre, si on accède directement à un fichier, ça passe crème.
C’est possible aussi avec Apache, presque pareil
Pour Apache, on peut également utiliser une directive <Location> pour protéger l’URL /, d’ailleurs le boulot est moins chiant que pour Nginx :
1 2 3 4 5 6 |
<Location ~ "^/$"> AuthType Basic AuthName "Acces restreint" AuthUserFile /chemin/vers/.htpasswd Require valid-user </Location> |
Comment contribuer ?
Etant donné que j’ai maintenant plus de moyens de contribuer (techniquement, publiquement, mais surtout financièrement), sous quelle forme je peux faire en sorte que le logiciel reste bien en vie, et pourquoi pas encourager plus activement l’auteur à défaut de pouvoir pousser du code (parce que moi et le Perl, c’est pas vraiment le grand amour) ? Je n’ai pas encore la réponse. Au moins ai-je proposé un cas d’usage, et je partage la solution. Maintenant que la solution fonctionne comme je l’entend, la prochaine étape est de se pencher sur l’identité visuelle, pour le mettre aux couleurs d’LBN. Il n’est évidemment pas question de masquer entièrement l’identité du logiciel ou de son auteur, mais tout comme Framasoft a personnalisé l’interface pour Framadrop, il est possible que je partage avec vous les détails de la personnalisation du thème de Lufi.
Salut,
Merci pour ce retour d’expérience, j’hésite toujours à proposer Lufi comme nouveau service pour Unixcorn. Je trouve le logiciel bien pensé, utile mais j’ai peur que cela consomme trop de ressources (surtout niveau stockage) sur une machine déjà bien utilisée.
Quelles limites as-tu mis pour l’envoi de fichier ?
Je serais aussi très intéressé par un retour sur la mise en place d’un nouveau thème ! Celui d’origine il faut le reconnaitre n’est pas très attrayant.
Merci et à la prochaine,
Il n’est pas encore en service, mais j’ai limité l’envoi à 1Go, avec suppression automatique si pas de consultation au bout de 30 jours. J’ai pas le fichier de conf en tête, faudra attendre mardi pour avoir plus de détails. Côté performances, comme le chiffrement/déchiffrement intervient côté client, c’est entièrement dépendant de celui-ci (puissance, débit réseau…). Niveau serveur ça mange rien, l’ELK qui tourne dans le vide à côté c’est pas la même chose.
Comment soutenir le logiciel ? Luc, son auteur, a un Tipee https://www.tipeee.com/fiat-tux et un libre pay
https://liberapay.com/sky/ pour lui donner des sous et le soutenir (ça l’aide).