Whatsapp (qui est chiffré sur une client lourd et non webapp, soit dit en passant, bonus par rapport aux mails)
Je ne vois pas en quoi le modèle de menace diffère. Quelle différence entre :
- une application web qui te pousse un javascript dont l'origine est authentifiée par l'utilisation de TLS, pour que le client puisse chiffrer une donnée avant de l'envoyer au serveur de l'éditeur ;
- et un client lourd, dont l'origine est authentifiée par la signature du package l'éditeur, qui chiffre une donnée avant de l'envoyer au serveur de l'éditeur ?
Dans les deux cas, l'accès aux données en clair peut avoir lieu par les scénarios suivants :
1. le terminal est compromis, et donc l'appel aux primitives de chiffrement est détourné, ou la mémoire directement observée, etc. ;
2. l'éditeur, malicieux, introduit un changement dans le code exécuté chez le client (mise à jour du javascript, de l'application mobile) pour se faire envoyer les clés ou la donnée elle-même en clair ;
3. l'éditeur, de bonne foi, se fait cependant (削除) poutrer (削除ここまで) infiltrer par un tiers qui opère le changement mentionné en 2., et donc tu comptes sur les compétences de l'éditeur en matière de gestion de la sécurité de son infrastructure.
Du coup, sur le point de la principale critique mentionnée dans le nourjal initial, j'aurais tendance à être d'accord avec la réponse apportée par ProtonMail : c'est valable pour tout service qui n'est pas sous ton contrôle. Client lourd ou non.
[^] # Re: Et si le chiffrement devenait un standard du web ?
Posté par boarf . En réponse au journal ProtonMail (et les autres webmails) chiffrés e bout en bout ne sont pas fiables. Évalué à 3.
Je ne vois pas en quoi le modèle de menace diffère. Quelle différence entre :
- une application web qui te pousse un javascript dont l'origine est authentifiée par l'utilisation de TLS, pour que le client puisse chiffrer une donnée avant de l'envoyer au serveur de l'éditeur ;
- et un client lourd, dont l'origine est authentifiée par la signature du package l'éditeur, qui chiffre une donnée avant de l'envoyer au serveur de l'éditeur ?
Dans les deux cas, l'accès aux données en clair peut avoir lieu par les scénarios suivants :
1. le terminal est compromis, et donc l'appel aux primitives de chiffrement est détourné, ou la mémoire directement observée, etc. ;
2. l'éditeur, malicieux, introduit un changement dans le code exécuté chez le client (mise à jour du javascript, de l'application mobile) pour se faire envoyer les clés ou la donnée elle-même en clair ;
3. l'éditeur, de bonne foi, se fait cependant
(削除) poutrer (削除ここまで)infiltrer par un tiers qui opère le changement mentionné en 2., et donc tu comptes sur les compétences de l'éditeur en matière de gestion de la sécurité de son infrastructure.Du coup, sur le point de la principale critique mentionnée dans le nourjal initial, j'aurais tendance à être d'accord avec la réponse apportée par ProtonMail : c'est valable pour tout service qui n'est pas sous ton contrôle. Client lourd ou non.