vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: TLS external => SASL external
Posté par Jehan (site web personnel, Mastodon) . En réponse à la dépêche XMPP au printemps, le grand rafraîchissement. Évalué à 2.
Salut,
vraiment désolé, je me suis emmêlé les pinceaux, et pourtant j'ai pas mal relu! Il s'agit de SASL external (c'est le protocole SASL qui gère l'identification). C'est le seul mécanisme décrit dans la RFC de base de SASL. Si on pouvait corriger la dépêche sur ce point svp!
En fait le principe de ce mécanisme est très simple. Il s'agit de dire "on s'est déjà identifié précédemment, tu te rappelles pas?". Cela implique une décision au niveau du protocole applicatif d'un autre moyen de s'identifier (SASL external est le plus générique des mécanismes et n'a aucun sens sans contexte). Dans le cas de XMPP, en S2S, nous nous reposons sur l'identification TLS.
Pour ceux qui ne savent pas comment marche TLS, il y a une partie vérification de l'identité d'un correspondant, avec les fameux certificats. Mais comme les certificats, c'est un concept difficile pour le grand public (= chiant, ils veulent juste un mot de passe, et basta! C'est parti mon kiki!), seul l'identité du serveur est vérifiée. C'est ce que fait aussi http avec https, sauf que nous, on rend ça obligatoire (ça veut pas dire que tous le font réellement malheureusement, mais ça veut dire qu'on dit aux développeurs de serveurs: si vous le faites pas, vous n'êtes pas une implémentation complète).
Or en S2S, c'est deux serveurs, donc normalement chacun doit avoir un certificat. Donc on est capable de créer une liaison TLS vérifiée des deux côtés. À partir de ce moment là, quand arrive le moment de l'identification, on peut dire "ah bah on fait, on se connaît déjà".
En gros donc, SASL external, pour le S2S XMPP, ça signifie juste (parce que c'est la définition qu'on a donnée) utiliser 2 certificats en TLS.
Et ça c'est autrement plus sécurisé que le protocole originel (à vrai dire, c'est ce qu'il y a de plus sécurisé dans ce genre de communications. Je parle bien sûr de notre contexte précis avec deux serveurs qui se connaissent pas outre mesure et qui ont cependant besoin de s'identifier et de crypter les communications, et aussi on fait avec les limites de TLS que nous connaissons tous ici car on arrive pas encore à trouver un meilleur système, du moins pas sur lequel tout le monde est d'accord).
Pour rappel, le Dialback, le principe c'était juste qu'on identifiait le serveur qui nous appelait en créant une second connexion dans l'autre sens et où on dit "c'est bien toi qui m'a appelé à l'instant et qui m'a dit ça?", ce qui rend très facile de se faire passer pour un autre serveur avec du DNS poisoning ou d'autres méthodes similaires.
NOTE: le SASL external peut théoriquement aussi être utilisé en C2S avec une clé cliente. Mais je sais pas si beaucoup de serveurs utilisent un tel système (peut-être sur des réseaux d'entreprises où on veut se passer de mot de passe?).
Je crois que c'est aussi utilisé par Google en C2S lorsqu'on est dans l'interface web gmail. Dans ce cas là, le SASL external, c'est "on s'est identifié quand on s'est identifié à l'email, pas la peine de le refaire pour XMPP!". Comme je disais, tout est une question de définition par le protocole applicatif.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]