Alex 🇮🇪 🇫🇷 is a user on mamot.fr. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

J'aime bien les éditeurs de logiciels privateurs « cloud » qui prétendent que c'est « secure et confidentiel parce que chiffrement coté client ». Soit
- Ils font leurs cryoto à leurs sauce, pas auditable. Et la crypto c'est pas leurs job
- Ils pompent lib crypto sous licence permissive, en font une boite noire inauditable et aucune valeur ajouté, ou ils modifient la lib à leurs sauce. Et la crypto c'est pas leurs job.
- Ils pompent une lib sous copyleft. Ils violent la licence + voir le cas n°2

@devnull Ça arrive très souvent.
Juste par curiosité, tu parles de quel logiciel la?

@roddhjav Je parle en général. Je vois souvent des prestaire de stockage en ligne ou des fabricants de disques durs qui vendent support de stockage en bundle avec abo stockge en ligne, balancer à leurs clients des clients de synchro privateurs « avec synchro ».

J'ai eu vu le cas le cas avec client proprio VPN (IPSec, OpenVPN et protocole pourri de M$ dont je sais plus le nom, auquel il faut une couche crypto à part). Je sais plus quel prestataire, mais eux c'est les champions de la décénie!

@devnull @roddhjav Un autre problème (en plus donc !) est que ce concept de chiffrement côté client présuppose qu'on ai une confiance aveugle (littéralement puisque pas auditable) dans le code client pour ne pas uploader ce qu'il n'est pas sensé uploader.

Par exemple une attaque ciblée serait facile pour protonmail (un exemple parmis tant d'autres) qui fournirais à la personne ciblée un code javascript modifié pour récupérer son mot de passe.

@roddhjav @devnull Donc méfiance quand un éditeur de logiciel dit "même si on le voulait on ne pourrait pas déchiffrer vos données", c'est absolument faux.

La seule protection est de ne pas être vulnérable si quelqu'un pénètre leur serveur ET qu'ils s'en rendent compte avant que les utilisateurs utilisent à nouveau le système compromis.

En revanche ça ne protège pas des (hypothétiques) mauvaises intentions de l'éditeur lui même.

@youen @roddhjav En pratique, ça protège de rien du.rout ouais. Ils ont les clés sur leurs serveurs pour chiffrer/déchiffrer, donc ils.se font.piquer les clés au passage en cas d'attaque externe

Cf la fuite de icloud il y a quelques années

@devnull @roddhjav Sauf si le chiffrement dépend du mot de passe utilisateur. Le problème étant alors qu'ils sont en excellente position pour le lui voler.

@roddhjav @devnull Et en plus les mots de passe utilisateur sont souvent très faibles.

@devnull @youen
Vous avez tout à fait raison. Cependant, dans la pratique ces boites noires ne sont pas toujours aussi noire.

1. On peut assez facilement vérifier ce que logiciel client envoie (via whireshark par ex). Si c'est pas chiffré, s’il envoie trop de chose... Par exemple si WhatsApp chiffre tous les messages de ses utilisateurs avec une clé de trop (la sienne), ca va se voir.

@devnull @youen
Mais c'est vrai que : c'est galère et pas infaillible, que le comportement du logiciel peut changer après une mise à jour et c'est bien pour ça que l'open source est toujours à recommander.

Alex 🇮🇪 🇫🇷 @roddhjav

@devnull @youen
2. Plus généralement, c’est implicite, mais l’hypothese de sécurité initiale quand vous installez un logiciel est que vous lui faites confiance, parce qu’il tourne sur un environnement de confiance et qu’il peut faire beaucoup de chose dessus. Donc ca signifie aussi que vous faites confiance à l’éditeur du logiciel. Dans le cas d’une boite noire, c’est plus ou moins une confiance aveugle au fournisseur de service.

· Web · 0 · 0

@devnull @youen
3. @youen Protonmail n’est pas le meilleur exemple, parce qu’ils sont quand meme costo en matierre de sécurité. De plus, la sécurité c’est leur business model contrairement à d’autre. Enfin c’est toujours important bien connaître leur model de menaces pour savoir si ca correspond au vôtre.
- protonmail.com/blog/protonmail
- protonmail.com/blog/encrypted_

@roddhjav @devnull Tout a fait, c'est ce que je voulais dire : le chiffrement de bout en bout ne vaut que si on fait confiance à l'éditeur. Ni plus ni moins :)

Le cas des outils "as a service" est plus risqué de manière générale car susceptible de changer le code côté client n'importe quand, et possiblement en ciblant un utilisateur particulier (donc les audit de code ou réseau ne vont rien voir)

@youen @roddhjav Si t'es visé particulierèment, t'es screwed dans tous les cas (sauf dans le cas où la cible se sait ciblée et est techniquement plus compétente que l'attaquant, dont les moyens seraient aussi limités. Mais ce cas n'existe pas en pratique. Quand quelqu'un ciblé, on y met les moyens en général et tu le sais pas. Si tu te sais ciblé autant rester très loin de tout ce qui électronique).