Posté par Samuel (site web personnel) .
Évalué à 10.
Dernière modification le 20 octobre 2023 à 21:41.
L'interception s'est faite en déroutant le trafic destiné au serveur vers un intermédiaire malveillant qui, du coup, a pu obtenir un certificat TLS valide via let's encrypt. Ça correspond à ce que propose le produit Jupiter, proposé par Nexa et vendu comme un logiciel d'interception légale (j'en parlais ici il y a quelques jours).
On note que les intercepteurs ont fait une petite boulette en oubliant de renouveller leur certificat a temps, ce qui a permis à l'administrateur système de détecter le problème.
Comme ils le notent en conclusion, la surveillance des journaux certificate transparency (cf. journal précédemment cité) aurait permis à l'administrateur de repérer le problème plus tôt. Ils notent aussi qu'on peut aussi demander à let's encrypt, via le DNS, de limiter la délivrance de certificats à un compte let's encrypt bien précis, de façon à empêcher l'attaque.
Hour compléter, côté XMPP, il est possible de faire du "channel binding" qui permet de s'assurer que les 2 machines à chaque bout d'une connexion ssl sont bien dans la même connexion ssl (sans intermédiaire au milieu comme ça semble être le cas ici).
Est-ce que ce serveur n'était pas configuré correctement pour le faire? Ou bien est-ce que l'attaquant a réussi à contourner ce mécanisme aussi?
omemo permet de chiffrer la communication de client à client. Mais dans XMPP il y a plein de trucs qui sont stockés sur le serveur, par exemple, la liste de contacts, l'historique des messages dans les canaux auxquels on est connecté (les messages peuvent être chiffrés de bout en bout mais ils sont quand même stockés), les messages reçus pendant que le client n'était pas connecté, …
De plus, l'attaque permet de s'insérer entre le client et le serveur et donc, par exemple, d'empêcher un client d'envoyer des messages, d'intercepter des messages (chiffrés de bout en bout, éventuellement, mais on peut essayer d'obtenir la clé par ailleurs), de remplacer la clé de chiffrement, d'injecter des messages comme s'ils étaient envoyés par un client (si on a besoin de fabriquer des preuves qu'un des utilisateurs du service est un terroriste, il suffit d'envoyer des messages non chiffrés par ce moyen… tant qu'on ne se fait pas détecter en tout cas).
Il faut donc sécuriser cet aspect de la connexion (du client vers le serveur) en plus du chiffrement de bout en bout (de client à client, via leurs serveurs XMPP respectifs), ainsi bien sûr que les connections de serveur à serveur.
# Le coupable probable : interception légale (et pieds nickelés)
Posté par Samuel (site web personnel) . Évalué à 10. Dernière modification le 20 octobre 2023 à 21:41.
L'interception s'est faite en déroutant le trafic destiné au serveur vers un intermédiaire malveillant qui, du coup, a pu obtenir un certificat TLS valide via let's encrypt. Ça correspond à ce que propose le produit Jupiter, proposé par Nexa et vendu comme un logiciel d'interception légale (j'en parlais ici il y a quelques jours).
On note que les intercepteurs ont fait une petite boulette en oubliant de renouveller leur certificat a temps, ce qui a permis à l'administrateur système de détecter le problème.
Comme ils le notent en conclusion, la surveillance des journaux certificate transparency (cf. journal précédemment cité) aurait permis à l'administrateur de repérer le problème plus tôt. Ils notent aussi qu'on peut aussi demander à let's encrypt, via le DNS, de limiter la délivrance de certificats à un compte let's encrypt bien précis, de façon à empêcher l'attaque.
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 3.
Hour compléter, côté XMPP, il est possible de faire du "channel binding" qui permet de s'assurer que les 2 machines à chaque bout d'une connexion ssl sont bien dans la même connexion ssl (sans intermédiaire au milieu comme ça semble être le cas ici).
Est-ce que ce serveur n'était pas configuré correctement pour le faire? Ou bien est-ce que l'attaquant a réussi à contourner ce mécanisme aussi?
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par barmic 🦦 . Évalué à 3.
À quoi ça sert ? Je veux dire la manière de répondre à ça c'est du chiffrement de bout en bout. C'est pas "simplement" omemo qui répond à ça ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par jnanar (site web personnel) . Évalué à 3. Dernière modification le 21 octobre 2023 à 07:41.
Il me semble qu'Omemo ne fonctionne pas dans les salons à plusieurs (muc). Dans ce cas-là cela pourrait avoir une utilité.
[^] # Re: Le coupable probable : interception légale (et pieds nickelés)
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5. Dernière modification le 21 octobre 2023 à 12:00.
omemo permet de chiffrer la communication de client à client. Mais dans XMPP il y a plein de trucs qui sont stockés sur le serveur, par exemple, la liste de contacts, l'historique des messages dans les canaux auxquels on est connecté (les messages peuvent être chiffrés de bout en bout mais ils sont quand même stockés), les messages reçus pendant que le client n'était pas connecté, …
De plus, l'attaque permet de s'insérer entre le client et le serveur et donc, par exemple, d'empêcher un client d'envoyer des messages, d'intercepter des messages (chiffrés de bout en bout, éventuellement, mais on peut essayer d'obtenir la clé par ailleurs), de remplacer la clé de chiffrement, d'injecter des messages comme s'ils étaient envoyés par un client (si on a besoin de fabriquer des preuves qu'un des utilisateurs du service est un terroriste, il suffit d'envoyer des messages non chiffrés par ce moyen… tant qu'on ne se fait pas détecter en tout cas).
Il faut donc sécuriser cet aspect de la connexion (du client vers le serveur) en plus du chiffrement de bout en bout (de client à client, via leurs serveurs XMPP respectifs), ainsi bien sûr que les connections de serveur à serveur.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.