@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

@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

Follow

@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

· · Web · 0 · 0 · 0
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.