@kalvn

Le truc de @framasky est déjà auto-hébergeable non ?
Il y a quelque chose de mieux dans le Send en question ?

@lienrag Tu parles de Framadrop je crois c'est ça ? Je ne sais pas s'il gère le chiffrement côté client mais Send le fait. Après, même s'ils sont équivalents en terme de fonctionnalités c'est toujours bien d'avoir différentes options :)

@kalvn Oui, Lufi¹ gère le chiffrement coté client²

1. C'est le nom de logiciel. Framadrop c'est le nom de lhinstance de framasoft. Comme mamot est le nom d'une instance Mastodon (le logiciel) et non pas le nom du logiciel.
2. Ça reste du chiffrement en javacript avec la clé contenue dans l'URL… C'est « pratique » pour le partage rapide. Ça ne replace du « vrai » chiffrement avec un outil desktop et des clér qui reste privées, si on parle de données sensibles.

@lienrag

@devnull @lienrag Merci je n'avais plus le nom de Lufi en tête :)

Oui ce n'est pas gage de sécurité à proprement parler, ça signifie juste que le serveur n'a pas accès aux fichiers uploadés ce qui peut rassurer si tu comptes proposer le service sur ton serveur à d'autres utilisateurs.

@kalvn Mouais, pour tout outil de chiffrement « coté client » basé sur du web… Ce n'est pas tout a fait vrai. Le serveur ne peut pas avoir accès au contenu QUE SI il ne logge pas toute la requête (tous les param d'URL, donc avec la clé).

En tant qu’utilisateurs d'un service en ligne géré par tiers, c'est juste impossible de vérifier ce que le serveur logge ou pas. Et ça peut être changé à tout moment par l'admin du serveur… À part choisir à qui faire confiance sans pouvoir contrôler

@lienrag

@kalvn Dans le meilleurs des cas, si l'admin est honnête, et vérifie correctement sa config de logs de serveur web… Ça protège *temporairement et uniquement anciens¹ en car où le serveur est troué. Si le pirate change le format de logs pour inclure tous les paramètres d'URL, il lui suffit d’attendre que les requêtes tombent pour récupérer les clés correspondantes..

Le seul moyen de vraiment chiffre coté client… C'est le le faire avec les bons outils, en dehors du web…

@lienrag

@kalvn

1. Anciens contenus. C'est à dire ceux mis sur le serveur avant qu'il se face troué et aux quelles plus personne n’accédera ni manuellement ni automatiquement (URL qui traînent dans des pages web (balises img ou équivalent)) après le piratage du serveur. Donc même si on choisi bien son instance et qu'en face y a admin honnête. Si jamais le serveur est troué par un tiens, toute requête après ça est potentiellement loggée à l'insu des utilisateurs et de l'admin…

@lienrag

@devnull @lienrag Oui et non, en principe ce genre d'outils web avec chiffrement côté client stockent la clé de déchiffrement dans le hash de l'URL (après le #) qui n'est pas envoyé par le navigateur au serveur. Donc si on s'en tient aux logs uniquement, la clé n'est pas censée apparaître côté serveur.

Après rien n'empêche l'hébergeur du service d'inclure un script côté client qui récupère le hash et l'envoie au serveur dans un second temps.

@kalvn @devnull

Normalement il devrait être possible de signer le javascript d'un site et de vérifier la signature avant exécution, non ?
Ce serait bien comme extension pour un navigateur et ça règlerait ce genre de problèmes...

@lienrag Pas si simple… Comment tu fait la différence avec une mise à jour légitime juste avec un hash. De plus on peut détecter curl ou « afficher source » et servir autre chose que le code servi au navigateur

@kalvn Bien sur que un hébergeur peut faire le con ailleurs aussi… J'ai jamais dit le contraire… Ce que j'ai dit que si t'as vraiment besoin de chiffrer, « dans le cloud » c'est de la merde, et qu'il faut chiffrer localement avec tes clés qui ne sont pas exposées… Rien d'autre…

Follow

@devnull

Ah c'est sûr que quand tu utilises un mode paranoÏaque, tu dois vérifier chaque mise à jour avant de l'accepter.

Pour ta deuxième remarque, le navgateur n'a aucun moyen de vérifier ce qu'il a reçu .?
Le javascript s'exécute bien côté client, non ?

@kalvn

@lienrag Si JS s’exécute coté client, mais ça ne change rien au problème.

Même s'il maintenait une correspondance https://domain.machin/vers/script-version-truc.js $hash… La moindre petite modif de script-version-truc.js provoque un changement de hash, sans aucun moyen (fiable) de différencier une mise à jour légitime d’une modif malveillance. C

@kalvn

@devnull
Oui ben donc le navigateur refuse toute les mises à jour, c'est bien le principe du mode paranoïaque.
Le jour où le serveur veut faire une mise à jour légitime, il prévient tout le monde et publie le nouveau hash en expliquant en quoi consiste la mofification du code.

@kalvn

@lienrag Et donc, ça prendre x ans pour déployer une màj… qui peut être urgence (faille de sécu)… C'est pas vraiment ce que j’appelle un moyen fiable…

Et ça laisse la porte ouverte aux dérives dans tous les cas (Par exemple jouer sur la peur d'une grosse faille pour faire accepter une mise à jour malveillante… Les gens ne prendront pas le temps d'auditer le nouveau code te vérifier que le annoncé hash correspond, à chaque màj avant d'accepter le nouveau hash, surtout quand ça urge… )

@kalvn

@devnull
Tant que le code est public, tu joues ta réputation dessus, donc il y a quand même forte incitation à ne pas faire n'importe quoi dessus...

@kalvn

@lienrag Y a trouzemelles bibliothèques JS pour faire des trucs meêm tout bêtes (is-odd, is-even, leftpad… ) et framework a la mode avec un changement tous les 4 matins parce que « c'est colol d'exprimenter » et les CDN dans tous les sens.…

Code public ou pas, personne n'a le temps t’auditer tout ça efficacement, contrôler la moindre modif et valider les modifs légitimes rapidement pour garantir les mises à jours rapides en cas de faille…

@kalvn

@lienrag

Et qui annonce les hash? Il se passe quand pendant ure faille de jquery¹, jquery.com se fait DDOS assez longtemps pour que personne ne puisse valider la mise à jour, et donc reste exposer pendant plus longtemps ? Ou si jquery.com¹ se fait trouver pour diffuser le hash d'une mise à jour qui corrige la faille mais en rajoute une autre discrètement pendant que tout le monde est trop occupé à ne penser qu'à l'ancienne faille ?

1. Ou autre. Peu importe

@kalvn

@lienrag Je crois que les acteurs malveillants n'ont un peu rien à foutre que pense du mal d'eux…

Déjà, les entreprises « sensées ne jamais faire des trucs stupide parce que une image de marque à soigner » ne se prive pas de nous entuber tous les jours parce que ça rapporte (capitalisme de surveillance, violations du RGPD, dark patterns et pièges dans les CGU en tout genre…) sans être inquiétées le moins du monde, tout en gardant l'extrême majorité de leurs clients…

@kalvn

@lienrag « jouer sa confiance en cas d'abus » c'est très insuffisant comme garde-fou… Son effet est à peu près entre négligeable et totalement nul.

@kalvn

@devnull

Vu qu'on parlait du servie de Framasky à la base, je ne le pense pas malveillant..

Pareil si la solution est implémentée par des acteurs comme Protonmail ou autre qui eux aussi font du chiffrement côté serveur, eux n'ont que leur réputation comme capital.

@kalvn

@lienrag J'ai jamais dit que lui l’était… Je le connais. Mais franchement, c'est un peu hors sujet… On parlais du navigateur qui vérifie le ce que le serveur lui balance.

Des applis web (avec ou sans chiffrement) en Javascript ne se résument pas à Lufi hein. Sans compter que Lufi peut être bien être modifié et hébergé par d'autres.…

Le problème concerne tout l’écosystème JS, entièrement basé sur une confiance aveugle dans trucs trop nombreux et trop changeants, pour être auditable…

@kalvn

@lienrag Le chiffremert d'email dans un navigateur web n'a absolument aucun sens… C'est du nivellement par le bas « parce que trop complikay » mais

1. Ça crée des risques qui n'existaient pas avec un bon vieux client mail lourd + GnuPG local¹
2. Des années après l'arrivée de protomail et as présentation comme solution utiltime, les gens ne chiffrent toujours pas leurs email massivement, même pas avec une solution techniquement casse-gueule

@kalvn

@lienrag

1. Par exepmle, entre 2 personnes qui utilisent GnuPG avec un client lourd, à aucun moment le serveur n'a possibilité d'accéder le contenu en clair. Le serveur ne peut pas exemple pas discrètement balancer un script faire une copie du email en clair dans thunderbird/clawsmail/whatever avant chiffrement.

@kalvn

@lienrag Alors que dans un webmail qui peut balancer ses scripts à tout moment et discriminer ce qu'il distribue si par ex il détecte un curl…, et que je peux pas auditer en étant certain que c'est les mêmes que le navigateur va exécuter à chaque utilisation… J'ai absolument pas les mêmes garanties. L'email fuiter via le webmail du l'expé ou du desti.

Même si OpenPGP a ses limiter : métadonnées. Te c'est pas des cochonneries dans un navigateur qui vont résoudre ce problème

@kalvn

@lienrag Donc même si un service de webmail était auditable avec la certitude que le code qui a été audité est même qui est distribué aux navigateurs web, et que les gens étaient assez formés et webmail parano pour éviter des webmail avec du code illisible, que gmail n'avait pas le quasi-monopole malgré ses abus… et que… Faudrait que tout le monde soit dev, capable de lire, JS, soit parano et avec assez de temps à perdre a chaque envoi d'email. Puisqu'on peut vérifier que son coté

@kalvn

@lienrag Pas le coté du destinataire… Ça n'a créer plus de problème que que n'en a résolu (à peu près 0). Et ça ne peut absolument rien contre les limites du chiffrement via un client « lourd¹ » (machine/OS compromis… là juste foutu dans un tel cas)

Si une agence à 3 (ou 4) lettres arrive à faire pression sur protonmail (ou équivalent par là je pense, tu perse qu'il se passera quoi?

1. Je me demande pourquoi ce terme… Les applis web sont plus lourdes en général… 🤡

@kalvn

Sign in to participate in the conversation
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!