Carnet de notes

Un espace de publi­ca­tion chif­fré côté client

Je ne veux plus gérer de serveur en ligne. Je me sens de moins en moins capable d’as­su­rer la sécu­rité d’un tel envi­ron­ne­ment 24/7 seul et sur mon temps person­nel. Je n’en ai pas la moti­va­tion, ne souhaite pas y inves­tir le temps néces­saire. Ne parlons même pas de la possi­bi­lité de prendre des congés deux semaines hors de France sans connexion Inter­net ni veille sécu­rité. Rien qu’a­voir ce blog sous word­press me gêne.

Je vais dépla­cer mes services sur un envi­ron­ne­ment mutua­lisé, géré par des profes­sion­nels qui ont les moyens, le temps et les compé­tences. Je vais en profi­ter 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 main­te­nance.

* * *

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

Je peux faci­le­ment trou­ver un héber­ge­ment mutua­lisé qui me permet de faire des accès restreints par authen­ti­fi­ca­tion HTTP ou avec un bout de PHP en façade, mais j’ai une confiance limi­tée dans la confi­den­tia­lité des fichiers que je peux poser sur un héber­geur mutua­lisé.

Du coup j’ima­gine utili­ser du chif­fre­ment côté client, avec un croi­se­ment entre Jekyll/Peli­can et 0bin/cryp­to­pad. Je chiffre les conte­nus lors de la géné­ra­tion et je les envoie chif­frés sur l’hé­ber­ge­ment. Les conte­nus sont déchif­frés dans le navi­ga­teur du client avec un gros bout de JS, en utili­sant un dérivé de mot de passe ou une clef cachée dans l’URL.

Le seul défaut que je vois c’est inter­dire l’ac­cès à ceux qui désac­tivent volon­tai­re­ment Javas­cript, et impo­ser un peu d’at­tente aux autres pour déver­rouiller les conte­nus : Pas idéal, pas perti­nent pour tous les usages, mais ici ça me semble accep­table.

* * *

Il y a 0bin et Cryp­to­pad (ainsi que d’autres) qui fonc­tionnent un peu sur ce prin­cipe, mais bran­cher ça dans Jekyll ou Peli­can me semble néces­si­ter un peu de travail, surtout si je veux avoir plus que du texte et que je veux présen­ter à l’uti­li­sa­teur unique­ment les liens auxquels il a accès.

Si vous connais­sez un CMS à publi­ca­tion statique qui a envi­sagé quelque chose du genre, je suis preneur.

Publié

dans

, , , ,

par

Éric

Étiquettes :

Commentaires

4 réponses à “Un espace de publi­ca­tion chif­fré côté client”

  1. Avatar de Éric
    Éric

    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é

    Répondre
  2. Avatar de Éric
    Éric

    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)

    Répondre
  3. Avatar de SesMan
    SesMan

    Quid de la syndication ? Les développeurs de nombreux nouveaux sites négligent cet outil dans leur implémentation…

    Répondre
    1. Avatar de Éric
      Éric

      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 e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *