Aujourd'hui, comme tous les 19 Mai, c'est Open Discussion Day, un "Jour" qui vise a promouvoir les outils libres de discussion instantanée. Le plus connu et répandu est bien entendu Jabber/XMPP.
Et justement, ce 19 Mai 2014 n'est pas comme les autres, puisque c'est aujourd'hui que les signataires du manifeste de chiffrement intégral des communications XMPP passent a l'action: a partir d'aujourd'hui, plus aucune connexion ne pourra être faite aux serveurs opérés par les signataires sans chiffrement (pour rappel, XMPP utilise TLS).
Alors bien sur, XMPP étant décentralisé, cela ne veut pas dire qu'aucun serveur n'acceptera une connexion en clair, mais en pratique tous les plus gros opérateurs feront ça. Si comme moi vous pensez que saybien, vous pouvez vous aussi refuser les communications non-chiffrées sans avoir besoin de signer ce manifeste.
Cette étape est la dernière étape du manifeste, qui n'est la que pour se mettre d'accord sur le fait que tout le monde doive chiffrer ses communications (XMPP n'oblige techniquement pas a chiffrer, il ne s'agit que d'un accord tacite… un peu comme utiliser 80 pour HTTP). A partir de la, on pourra avancer ensemble sur les autres éléments de la sécurité au sens large:
- l'authentification de la connexion, possible grâce aux certificats TLS, mais difficile a mettre en place parce que ces certificats doivent être acceptée par une CA reconnue, avec tous les problèmes que ça pose
- le chiffrement bout-en-bout, possible grâce a OTR ou PGP mais pas encore standardisé
Si vous songez a administrer votre propre serveur XMPP, je ne peux que vous conseiller Prosody, simple et performant. Tellement simple que pour faire comme les autres et refuser les communications non chiffrées, c'est 2 options dans le fichier de configuration.
Note: Ce contenu est placé sous licence CC0
# Google
Posté par BFG . Évalué à 5.
Qu'en est-il de gmail aujourd'hui, qui ne supportait pas TLS pour le S2S ?
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 4.
Déjà ils ne gèrent plus trop xmpp alors…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google
Posté par Maxime (site web personnel) . Évalué à 4.
Ne mélangeons pas tout. Le serveur parle très bien le XMPP. Ce qui a changé c'est surtout leur client web : plus possible de voir et discuter avec des gens sur un serveur non google, visio-conf sur un protocole que seuls eux comprennent.
Si tu utilises un client XMPP avec un compte Google, ça ne changera pas grand chose pour toi.
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 7.
XMPP non fédéré avec des extensions proprios, c'est en pratique pour l'utilisateur tout comme s'ils utilisaient un autre protocole.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google
Posté par Maxime (site web personnel) . Évalué à 2.
C'est vrai que la visio entre un type sur pidgin et un autre sur gajim ou jitsi, ça marche beaucoup mieux… Si tu veux pouvoir discuter avec des gens qui sont pas sur un compte Google alors tu n'utilises pas le client web de Google mais un autre soft.
Je suis d'accord sur le fond, je déplore fortement ce choix politique. Et pire encore, s'ils ont bloqué la fédération sur niveau client web, pourquoi s'arrêter là et ne pas le faire niveau serveur ? Je dis juste une chose : soyons précis.
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Sans doute pour lentement, mais sûrement enterrer la fédération en évitant une levée de boucliers.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google
Posté par barmic . Évalué à 2. Dernière modification le 20 mai 2014 à 09:33.
Procès d'intention ? ÀMHA ils ont plutôt des problèmes techniques pour arriver à avoir ce qu'ils veulent avec XMPP, sinon ils auraient fait comme ils l'ont déjà fait en poussant jingle (d'ailleurs à l'époque ça n'avait pas plus parce que tout le monde en parlait depuis des années et que eux sans perdre leur temps à discuter des titres et des sous-titre de chaque XEP avaient implémentés le bouzin).
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 2. Dernière modification le 20 mai 2014 à 09:50.
Google a du mal à faire un client web XMPP? C'est vrai qu'ils manquent un peu de moyens par rapport aux mégas corporations derrière Sàt ou Jappix.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google
Posté par claudex . Évalué à 5.
Non Google a dû mal à avoir un produit qui correspond à ce qu'il veut et qui respecte les standards XMPP. Prenons l'exemple de la vidéo, ils avaient besoin d'un protocole tout de suite, pas 2 ans plus tard, du coup, le standard XMPP n'était pas compatible avec ce que Google utilisait.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 1.
Aujourd'hui c'est le chat en mode texte à deux utilisateurs tout simple qui n'est plus disponible pour les utilisateurs qui sont passés à hangouts. Rien avoir avec la vidéo ou une extension complexe.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Google
Posté par claudex . Évalué à 3.
Qu'est-ce que tu en sais ? Par exemple, il y a la date de vue du post dans Hangout, il ne me semble pas que les clients XMPP le gère. Et il y a peut-être d'autres trucs derrière qui ne sont pas directement visible.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Google
Posté par Maxime (site web personnel) . Évalué à 7.
Google a largement les moyens techniques de faire ce qu'ils veulent. Il y a même des ingés de Google prêts à utiliser leurs 20% project pour améliorer la compatibilité. Sauf qu'ils ont décidé de pas le faire. Une des raisons pour la fédération est par exemple pour éviter le spam en provenance de serveurs extérieurs (heureusement qu'ils ne sont pas en position de faire pareil avec le mail…).
Pour tout ce qui est protocoles non standards, c'est simple : proposer un produit innovant de son côté c'est plus simple seul qu'en essayant en plus de le rendre standard, passer du temps dans des réunions pour définir un standard c'est lourd et c'est lent. Ils veulent proposer rapidement un produit, et visiblement faire plaisir aux geeks en faisant les choses bien a perdu de son importance avec le temps.
[^] # Re: Google
Posté par Maxime (site web personnel) . Évalué à 2.
Je ne suis pas sûr de comprendre ce que tu dis. Je discute depuis mon gajim (avec un compte gmail) avec des gens sur hangout en mode texte.
[^] # Re: Google
Posté par devnewton 🍺 (site web personnel) . Évalué à 3. Dernière modification le 20 mai 2014 à 11:04.
Oui ça ne marche qu'avec des comptes gmail.
C'est subtil: ils n'ont pas arrêté la fédération d'un coup, mais dans des conditions (utilisateurs passés à hangouts + interface web), les messages ne sont notifiés, mais archivés directement.
A chaque fois, il faut de longues explications et tests pour faire comprendre ce qui se passe, mais au final si tu veux correspondre avec un utilisateur de gmail dans de bonnes conditions, il te faut un compte gmail.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
# Merci !
Posté par Framasky (site web personnel) . Évalué à 2.
J'étais pas au courant, mais comme c'est une très bonne chose, je me suis empressé de bloquer les connexions non chiffrées.
Merci :-)
Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Ah, Prosody !
Posté par flan (site web personnel) . Évalué à 5.
J'avais regardé il y a quelques temps différents serveurs XMPP, et Prosody est apparu comme nettement au-dessus du lot. La doc est claire, il est facile à installer, il fait « propre », les erreurs sont claires et explicites, il y a beaucoup d'options et de possibilités. Rien à voir avec ejabberd.
Le seul reproche que je lui fais est l'absence de gestion de Kerberos pour l'authentification.
[^] # Re: Ah, Prosody !
Posté par Maxime (site web personnel) . Évalué à 2.
Pour l'auth, tu peux pas contourner en utilisant soit un script soit pam ?
[^] # Re: Ah, Prosody !
Posté par flan (site web personnel) . Évalué à 1.
Oui et non.
Oui, parce qu'en effet, tu peux demander à l'utilisateur d'entrer son mot de passe et le valider via un script (ou via PAM).
Non, parce que le but de Kerberos est (entre autres) de ne pas avoir à fournir de mot de passe en permanence (l'autre but étant que ton mot de passe ne circule pas — tu peux donc t'authentifier même sur un réseau en clair). L'idéal étant de ne pas en avoir du tout, par exemple avec un certificat + clef privée stockés sur une carte à puce qui te permettent d'obtenir un ticket Kerberos (sachant que la clef privée ne quitte à aucun moment la carte à puce), et à partir de là, tu t'authentifies sur tous les services de façon transparente.
# OTR
Posté par tuxicoman (site web personnel) . Évalué à 1.
OTR, c'est le truc révolutionnaire qui plante quand on change de client (passage du smartphone au PC par exemple) ou qu'on l'éteint (j'éteins parfois mon logiciel de messagerie). Bravo. Déja XMPP, avec son multi-ressoureces non synchronisées sur la même adresse foutait le bazar mais là c'est le ponpon, en plus les messages recus sont illisibles.
Si je rajoute à ça ceux qui veulent utiliser XMPP en mode asynchrone (laisser des messages à des correspondants hors ligne) pour lesquels la négociation OTR préalable n'est pas possible par principe, c'est une belle blague.
OTR, c'est sûrement bien d'un point de vue crypto mais ca ne s'applique pas très bien au multi client asynchrone. Hors c'est quand même l'usage courant d'une messagerie aujourd'hui.
[^] # Re: OTR
Posté par yeahman . Évalué à 1.
Du coup, ça veut dire que si t'es en hors-ligne et qu'on t'envoie un message, tu pourras pas le déchiffrer ou alors tu le recevras pas ?
Ou alors le correspondant pourra pas l'envoyer si je comprends bien.
Mais c'est pas possible de le faire pour les personnes avec qui tu as confirmé au moins une fois les clés et que tu l'as ajouté comme correspondant de "confiance" ?
[^] # Re: OTR
Posté par rakoo (site web personnel) . Évalué à 3.
Il ne sera même pas possible de commencer une conversation OTR.
Pour en commencer une, il faut deux clés: la clé long-terme (celle que tu vérifies et valide) et la clé court-terme, qui est créée pour chaque échange. Puisque l'autre est hors-ligne, tu n'auras pas cette clé.
[^] # Re: OTR
Posté par rakoo (site web personnel) . Évalué à 3.
Ça c'est parce que les implémentations n'ont pas pris ce détail en compte: rien n'interdit un même JID d'avoir plusieurs empreintes OTR différentes. C'est pas un problème lié seulement au protocole.
Et justement, Moxie Marlinspike et sa clique ont développé un OTR avec un protocole un peu different, qui a plusieurs vertus intéressantes:
C'est utilisé dans TextSecure et même dans Pond, mais malheureusement personne n'a encore fait quoi que ce soit pour essayer d'importer ça dans XMPP…
[^] # Re: OTR
Posté par mathieui (site web personnel) . Évalué à 4.
Oui mais non. Tu peux en effet avoir plusieurs empreintes de clefs par JID, la plupart (tous les ?) des clients qui prennent en charge OTR prennent ça en charge également. Cependant, le problème est différent : tu ne peux pas maintenir une conversation OTR sur plusieurs terminaux connectés, pour la bonne et simple raison que le chiffrement se fait pour une clef en particulier, les messages via OTR dupliqués sur un autre terminal (ils ne le devraient pas quand c’est fait proprement, cf XEP-0280, XEP-0334) seront illisibles, quoi que tu fasses. Le seul truc que tu peux faire quand tu changes de terminal, c’est rouvrir une session OTR avec ton contact.
Ce problème n'est par ailleurs pas résolu dans le protocole de TextSecure, puisque le protocole suppose que la master key reste la même entre les messages.
Le seul contournement reste encore et toujours de dupliquer la clef entre les différents terminaux afin d’en avoir une seule.
[^] # Re: OTR
Posté par rakoo (site web personnel) . Évalué à 3.
De mémoire, Jitsi ne permet pas d'associer un contact avec plusieurs empreintes. Mais j'ai teste ça ya un bout de temps, ça a peut-être change depuis.
Sinon tu as raison, on est plus ou moins dans le même problème que les conversations OTR a plusieurs, qui est toujours non résolu.
[^] # Re: OTR
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
OTR n'a rien à voir avec XMPP, c'est un bricolage de l'utiliser avec, dont l'intérêt principal est à mon sens est d'être utilisable avec les passerelles (c.-à-d. quand on sort de XMPP). Ce n'est certainement pas la méthode qui va être standardisée (pas plus que PGP qui était un usage historique maintenant obsolète). Le journal est d'ailleurs faux sur ce point.
La méthode propre passe par jingle et est en cours de travail: http://xmpp.org/internet-drafts/draft-meyer-xmpp-e2e-encryption-02.html . Il y aussi quelques XEPs par ci par là mais je ne les connais pas encore, je ne sais pas ce qu'elle valent (XEP-0200 par exemple).
OTR est censé être utilisé sur l'instant, comme un journaliste parlerait à une de ses source: sur le moment il sait à qui il parle, mais après coup on ne peut plus le prouver. Ça n'est pas fait pour laisser des messages hors ligne, ni même pour quoi que ce soit d'autre que de la discussion instantanée (pas de mise en forme, pas d'état de discussion, pas de correction de message, etc. Les clients qui font de la mise en forme font aussi un bricolage, ça devient du bricolage par dessus du bricolage).
ça veut dire quoi multi resources non synchronisées sur la même adresse ? Le sysème de resources de XMPP fonctionne très bien, quel est ton problème au juste ?
[^] # Re: OTR
Posté par rakoo (site web personnel) . Évalué à 2.
A mon avis ça veut dire que XEP-313 (Recuperation des messages stockés sur le serveur) et XEP-280 (Envoi du message a toutes les ressources connectées) ne sont pas suffisamment déployés: moi-même j'ai choisi yaxim plutôt que Chatsecure parce que ce dernier ne supporte pas la XEP-280, ce qui fait que j'avais des bouts de conversation a droite que j'avais pas a gauche.
[^] # Re: OTR
Posté par Goffi (site web personnel, Mastodon) . Évalué à 2.
Oui je pense aussi que c'est plutôt l'absence de MAM (la 0313) qui pose problème, mais j'aurais voulu avoir confirmation
[^] # Re: OTR
Posté par SwordArMor (site web personnel) . Évalué à 1.
En quoi PGP est-il obsolète ? C’est encore très utilisé pour chiffrer des mails et tisser un réseau de confiance. La plupart (toutes ?) les distributions GNU/Linux se basent d’ailleurs sur PGP pour vérifier les paquets que tu télécharges.
[^] # Re: OTR
Posté par Goffi (site web personnel, Mastodon) . Évalué à 3.
Ce n'est pas PGP lui même qui est obsolète, c'est l'utilisation de PGP avec XMPP, cf XEP-0027.
[^] # Re: OTR
Posté par SwordArMor (site web personnel) . Évalué à 1.
Si tu ne veux pas être soumis aux aléas des implémentations, tu peux simplement copier ta paire de clé entre tes différents appareils. Je balance entre trois clients (un sur le fixe, un sur le laptop et un dans un tmux sur mon serveur pour rester connecté) et je n’ai jamais eu de souci.
Il suffit de laisser un client tourner dans un coin de serveur comme le font tout ceux qui veulent rester connecter sur IRC.
[^] # Re: OTR
Posté par claudex . Évalué à 5.
Si ça ne résout pas les problèmes d'IRC, je ne vois pas l'intérêt de l'utiliser.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.