@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


@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

Follow

@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

· · Web · 1 · 0 · 0

@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
La Quadrature du Net - Mastodon - Media Fédéré

Mamot.fr est une serveur Mastodon francophone, géré par La Quadrature du Net.