tchapgouv / tchap-product

Discussions sur les différents points de design
3 stars 0 forks source link

Session vérifiée incapable de déchiffrer les messages #230

Closed NicolasBuquet closed 5 hours ago

NicolasBuquet commented 7 months ago

Histoire qui m'est arrivée la matinée du 13/11/2023.

Pour des soucis d'identification sur un autre site du gouvernement ouvert dans un onglet à côté de celui de Tchap, j'ai dû supprimer les cookies et données de compte de Firefox.

Cela impacte donc l'onglet de Tchap qui perçoit bien la suppression et affiche une pop-up

Screenshot 2023-11-13 at 17 13 34

Suite à cela, recharger la page du navigateur m'amène sur la page de login (normal).

Je me loggue et me retrouve donc sur une session non vérifiée dans laquelle tous les messages sont chiffrés (normal).

Tchap web me propose de vérifier la session. Je choisis de la vérifier à l'aide d'un autre appareil, ayant mon Tchap iOS à jour à portée de main.

Je vérifie par QRCode en scannant à l'aide de Tchap iOS le QRCode que me présente Tchap web.

La vérification se déroule avec succès. Ma session Tchap web est déclarée vérifiée.

Mais mes messages restent chiffrés.

Détectant alors une anomalie de fonctionnement je vérifie l'état de Tchap web :

Screenshot 2023-11-13 at 11-29-15 Tchap 10 Tchap - Dev Mobile FR

Ce dernier point me semble étrange, la sauvegarde automatique des message étant activée sur mon compte.

Je vérifie dans les paramètres de Tchap iOS :

IMG_7983

On voit que l'appareil iOS sauvegarde les messages et d'ailleurs que la session web est vérifiée.

Côté web, la session est vérifiée aussi bien sûr :

Screenshot 2023-11-13 at 11-29-54 Tchap 10 Tchap - Dev Mobile FR

J'essaie alors de refaire quand même une vérification de session web. Celle-ci ne me propose alors que de saisir le code de récupération :

Screenshot 2023-11-13 at 11-31-19 Tchap 10 Tchap - Dev Mobile FR

N'ayant pas ce code de récupération sous la main, et voyant que la version web est un peu perdue (elle est vérifiée mais n'arrive pas à déchiffrer les messages), j'essaie de lui vider le cache pour qu'elle reparte sur de meilleures bases :

Screenshot 2023-11-13 at 11-32-14 Tchap 10 Tchap - Dev Mobile FR

Cela ne change rien à la situation précédente :

Screenshot 2023-11-13 at 11-33-25 Tchap 10 Tchap - Standup du matin - Daily

Voyant que je vais avoir besoin du code de récupération, je décide d'en régénérer un sur Tchap iOS qui est à jour du flux de messages et qui les déchiffre tous.

Je génère donc un nouveau code de récupération, opération qui est immédiate alors sur l'iPhone.

J'essaie d'utiliser ce nouveau code de récupération sur web :

Screenshot 2023-11-13 at 11-39-41 Tchap 10 Tchap - Dev Mobile FR

Après saisie du code par copier-coller, voulant vérifier autre chose avant de valider le code, j'appuie sur ESCAPE pour annuler la pop-up de saisie du code de récupération.

Cela semble valider le code !

Car le code est refusé par Tchap web, alors qu'il vient tout juste d'être généré par Tchap iOS :

Screenshot 2023-11-13 at 11-39-55 Tchap 10 Tchap - Dev Mobile FR

Ne comprenant pas pourquoi, je regarde dans quel état est la version web :

Screenshot 2023-11-13 at 11-40-54 Tchap 10 Tchap - Dev Mobile FR

Sont état a complètement changé alors que la clé de récupération a été refusée par le client Tchap web !

Trouvant que la saisie du code de récupération validée par la touche ESCAPE était peu orthodoxe, je décide de retenter la génération d'un code de récupération sur l'iPhone pour le saisir et valider proprement côté web.

Je régénère donc le code sur iPhone.

Cette fois, l'opération n'est pas immédiate. Elle prend de l'ordre de 40 secondes.

L'application web réagit au bout de ce temps : une pop-up m'informe que "Un nouveau Code de Récupération pour les messages sécurisés a été détecté.".

Screenshot 2023-11-13 at 11-43-05 Tchap 10 Tchap - Dev Mobile FR

Je vérifie à nouveau l'état du client Tchap web :

Screenshot 2023-11-13 at 11-46-16 Tchap 10 Tchap - Dev Mobile FR

La session est dans le même état que précédemment à l'exception de la version de la sauvegarde :

Je me dis que, bien que le processus se déroule bizarrement, au moins l'état progresse.

Mes messages sont toujours chiffrés.

Je décide d'essayer de "Récupérer mes messages". Je clique donc sur le bouton correspondant.

L'application web me demande à nouveau le code de récupération :

Screenshot 2023-11-13 at 11-47-08 Tchap 10 Tchap - Dev Mobile FR

Je ne le saisis pas tout de suite, car il se passe quelque chose en arrière-plan : les messages se déchiffrent !

Untitled

Je vérifie encore l'état de la session, n'ayant pas validé la récupération de message car je n'ai même pas saisis le code de récupération demandé :

Screenshot 2023-11-13 at 11-48-31 Tchap 10 Tchap - Dev Mobile FR

L'état est le même que précédemmant à l'exception de le note : "Cette sauvegarde est fiable car elle a été restaurée sur cette session".

Comment un simple utilisateur peut-il s'en sortir lorsqu'il rencontre une telle situation ?

Que s'est-il passé ? Le saurons-nous un jour ? :smile:

NicolasBuquet commented 7 months ago

Piste envisagée :

Cela demande :

@odelcroi @yostyle @estellecomment @jdauphant Vos avis ?

odelcroi commented 7 months ago

Piste envisagée : supprimer la vérification de session sous quelque forme que ce soit ne permettre de récupérer une session que par le code de récupération

Je ne comprend pas ce que tu veux dire par supprimer la vérification de session?

Dans une cinématique aussi longue, il faut essayer d'isoler et de reproduire les problèmes.

estellecomment commented 7 months ago

Des remarques :

Pour le probleme plus général :

Idées :

jdauphant commented 7 months ago

Piste envisagée :

  • supprimer la vérification de session sous quelque forme que ce soit
  • ne permettre de récupérer une session que par le code de récupération

Cela demande :

  • d'identifier dans quelles conditions le client web ne propose que la saisie du code de récupération pour vérifier une session
  • s'assurer que quelle que soit l'état de la session, si une sauvegarde automatique est présente sur le back-end, la saisie du code de récupération permet de ramener le client (web ou mobile) dans un état à jour, déchiffré et utilisable.

@odelcroi @yostyle @estellecomment @jdauphant Vos avis ?

Le scénario envisagé :

Solution pour sortir de ce problème

Solution pour éviter ce problème

Infos importantes :

NicolasBuquet commented 7 months ago

Piste envisagée : supprimer la vérification de session sous quelque forme que ce soit ne permettre de récupérer une session que par le code de récupération

Je ne comprend pas ce que tu veux dire par supprimer la vérification de session?

Dans une cinématique aussi longue, il faut essayer d'isoler et de reproduire les problèmes.

@odelcroi

Il faut bien sûr identifier le problème et le résoudre.

Quand j'évoque la suppression de la vérification de session, c'est à terme, pas en palliatif pour masquer le problème rencontré.

NicolasBuquet commented 7 months ago

@estellecomment Lors de ma session sous Firefox, après saisie du code de récupération, l'appui sur ESC à validé l'input.

Je n'arrive pas à le reproduire sous Safari dans le cas suivant :

L'UI me ramène bien à la pop-up de choix de méthode de vérification.

La procédure de vérification n'est pas lancée suite à l'appui sur ESC.

yostyle commented 7 months ago

@jdauphant

* Tu valides la session web avec iOS, le web récupére la clé de signature croisée, il est validé et mais il peut sauvegarder mais n'a pas accès au secure storage permettant de déchiffré le backup. Le web peut sauvegarder

Attention car dans la copie d'écran on contaste que le session web ne possède pas les clés privées de la signature croisée. Cela signifie que le client web n'a pas reçu les clés de signature croisée ou ne les a pas pris en compte.

@estellecomment Autre point important, on indique à l'utlisateur que la signature croisée est activée sur l'appareil alors qu'ils ne possèdent les clés privées.

image

On constate que le client iOS considère que la session web est vérifiée alors que le web attend toujours les clés de signature croisée

jdauphant commented 7 months ago

@jdauphant

* Tu valides la session web avec iOS, le web récupére la clé de signature croisée, il est validé et mais il peut sauvegarder mais n'a pas accès au secure storage permettant de déchiffré le backup. Le web peut sauvegarder

Attention car dans la copie d'écran on contaste que le session web ne possède pas les clés privées de la signature croisée. Cela signifie que le client web n'a pas reçu les clés de signature croisée ou ne les a pas pris en compte.

@estellecomment Autre point important, on indique à l'utlisateur que la signature croisée est activée sur l'appareil alors qu'ils ne possèdent les clés privées.

image

On constate que le client iOS considère que la session web est vérifiée alors que le web attend toujours les clés de signature croisée

Ok du coup, la situation est pire que ce que ce qui est décrit dans mon scénario.