Un espace de publication chiffré côté client

Je ne veux plus gérer de serveur en ligne. Je me sens de moins en moins capable d’assurer la sécurité d’un tel environnement 24/7 seul et sur mon temps personnel. Je n’en ai pas la motivation, ne souhaite pas y investir le temps nécessaire. Ne parlons même pas de la possibilité de prendre des congés deux semaines hors de France sans connexion Internet ni veille sécurité. Rien qu’avoir ce blog sous wordpress me gêne.

Je vais déplacer mes services sur un environnement mutualisé, géré par des professionnels qui ont les moyens, le temps et les compétences. Je vais en profiter pour passer à peu près tout en fichiers HTML statiques. Publier des fichiers html, css et images sur un espace à 2€, ça limite pas mal la maintenance.

* * *

Mon problème c’est que j’ai aussi des parties de site à accès restreint, avec des documents qui ne doivent pas sortir n’importe où.

Je peux facilement trouver un hébergement mutualisé qui me permet de faire des accès restreints par authentification HTTP ou avec un bout de PHP en façade, mais j’ai une confiance limitée dans la confidentialité des fichiers que je peux poser sur un hébergeur mutualisé.

Du coup j’imagine utiliser du chiffrement côté client, avec un croisement entre Jekyll/Pelican et 0bin/cryptopad. Je chiffre les contenus lors de la génération et je les envoie chiffrés sur l’hébergement. Les contenus sont déchiffrés dans le navigateur du client avec un gros bout de JS, en utilisant un dérivé de mot de passe ou une clef cachée dans l’URL.

Le seul défaut que je vois c’est interdire l’accès à ceux qui désactivent volontairement Javascript, et imposer un peu d’attente aux autres pour déverrouiller les contenus : Pas idéal, pas pertinent pour tous les usages, mais ici ça me semble acceptable.

* * *

Il y a 0bin et Cryptopad (ainsi que d’autres) qui fonctionnent un peu sur ce principe, mais brancher ça dans Jekyll ou Pelican me semble nécessiter un peu de travail, surtout si je veux avoir plus que du texte et que je veux présenter à l’utilisateur uniquement les liens auxquels il a accès.

Si vous connaissez un CMS à publication statique qui a envisagé quelque chose du genre, je suis preneur.

Rejoindre la conversation

4 commentaires

  1. Pour suivre les discussions qui ont eu lieu avant la publication de ce billet : Oui je suis au courant que la crypto dans le navigateur a ses limites.

    Déjà je ne m’occupe que de déchiffrer donc toutes les limitations à propos des générateurs aléatoires ne me concernent pas. Le reste est surtout lié à mon modèle de menace.

    Je crains des gens qui font fuiter des fichiers, soit parce qu’ils y ont accès au niveau de l’hébergeur soit parce qu’ils y ont exploité de manière relativement aveugle une faille de sécurité. Pas que mes contenus aient une quelconque valeur pour un tiers, mais leur diffusion serait quand même significativement dommageable.

    Je ne vois toutefois pas quelqu’un viser spécifiquement mon hébergement, corrompre le serveur, et modifier mon Javascript pour ensuite faire fuiter les clefs ou le contenu. Je ne dis pas que ça ne peut pas arriver, mais l’effort à fournir me parait largement dépasser le gain que quiconque pourrait y trouver.

    Si quelqu’un le fait, il aurait tout aussi facilement pu trouver un problème de configuration ou de mise à jour dans mon serveur actuel… ou dans ce wordpress. Du coup ça sera dans tous les cas façons un « mieux » côté sécurité

  2. Pour le chiffrement, on l’état de l’art c’est partir d’un mot de passe demandé à l’utilisateur ou d’une chaîne base64 aléatoire stockée dans le lien d’accès après le #. Les deux restent côté navigateur et ne devraient pas fuiter sur le réseau. À partir de ça on dérive avec PDKF2 ou un système similaire pour créer une clef utilisateur.

    Chaque contenu sur le serveur est chiffré avec une clef symétrique type AES. Cette clef primaire est elle-même stockée à côté du contenu, et chiffrée par la clef utilisateur.

    * * *

    Un même utilisateur peut donc potentiellement déchiffrer plusieurs types de contenus différents. Il suffit qu’on ait laissé une version de chaque clef primaire, chiffrée à son attention.

    Inversement, un même contenu peut être distribué à plusieurs utilisateurs. Il suffit de stocker plusieurs copies de la clef primaire, chiffrées avec les différentes clef utilisateur concernés.

    La conjonction des deux fait qu’on peut retirer des accès à quelqu’un sans couper les accès des autres (on change la clef primaire à volonté, et il suffit de ne plus chiffrer les nouvelles clefs primaires avec les clefs des utilisateurs révoqués)

    1. Le principal reste public et n’a aucune raison d’être chiffré. Je compte bien avoir un fichier Atom quelque part.

      Les parties privées, pour mon cas d’usage, il n’y a pas de sens à les syndiquer, donc ça me simplifie le problème. J’imagine que sinon il y aurait toujours moyen de faire des Atom spécifiques avec juste des liens.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

À propos de ce site, du contenu, de l'auteur
Je poste parfois ici des humeurs ou des pensées. Parfois je change, parfois je me trompe, parfois j'apprends, et souvent le contexte lui-même évolue avec le temps. Les contenus ne sont représentatifs que de l'instant où ils ont été écrits. J'efface peu les contenus de ce site, merci de prendre du recul quand les textes sont anciens. Merci

À toutes fins utiles, ce site est hébergé par OVH SAS, joignable par téléphone au +33 (0)9 72 10 10 07 et dont le siège social est au 2 rue Kellermann, 59100 Roubaix, France.