La fondation XMPP donne le signal d'un chiffrement généralisé des échanges

La fondation XMPP donne le signal d’un chiffrement généralisé des échanges

Seulement une première étape

Avatar de l'auteur
Vincent Hermann

Publié dans

Internet

21/05/2014 5 minutes
15

La fondation XMPP donne le signal d'un chiffrement généralisé des échanges

Le XMPP est un protocole utilisé essentiellement pour les solutions de messagerie, mais son usage peut être plus général. Dans un monde marqué par l’actualité sur la sécurité des données, la XMPP Standards Foundation a annoncé lundi le démarrage d’une opération visant le chiffrement des connexions pour un maximum de services utilisant le protocole.

xmpp facebook
Marco Barisione (licence CC BY 2.0)

XMPP, un protocole largement utilisé 

XMPP, pour Extensible Messaging and Presence Protocol, est en fait l’ancien Jabber. Ce protocole est utilisé par de nombreuses entreprises. Par exemple, Google l’utilise comme fondement de son système de messagerie depuis des années. Facebook assure également une compatibilité XMPP depuis longtemps, mais avec une date d’arrêt fixée au 30 avril 2015. IBM, Oracle, Cisco ou même encore Apple disposent de produits qui utilisent ou sont compatibles avec XMPP.

 

Si XMPP est largement utilisé, il n’obéit pas strictement à un organe centralisé. Il s’agit d’un protocole ouvert que les entreprises peuvent manier comme bon leur semble. Deux produits utilisant XMPP ne sont ainsi pas nécessairement compatibles entre eux. Google par exemple n’utilise pas toutes les fonctionnalités du protocole. Une discussion entre un compte Google et un autre, utilisant un serveur XMPP plus complet, ne permettra donc pas de réaliser toutes les actions possibles.

Le début d'un effort généralisé de chiffrement des données 

La situation pourrait devenir plus complexe pendant un certain temps. La XMPP Standards Foundation a en effet préparé depuis longtemps le terrain pour mettre en place un chiffrement des données chez autant d’acteurs que possible. Une étape importante dans un monde particulièrement marqué par les actualités sur les fuites de données et failles de sécurité, sans parler de l’impact du vol des documents de la NSA par le lanceur d’alertes Edward Snowden.

 

Cet effort de chiffrement concerne avant tout les communications client/serveur et n’est d’ailleurs qu’une première étape, même si elle est cruciale. Dans la pratique, cela touche essentiellement les serveurs car la plupart des clients gèrent le chiffrement des données. En fonction du service que vous utilisez, il est possible que vous rencontriez certaines difficultés en ce moment, les changements étant appliqués depuis lundi.

TLS 1.2 est à préférer pour tous les échanges 

Les échanges qui ne le faisaient pas vont donc employer désormais TLS (Transport Layer Security). Le chiffrement des connexions ne représente évidemment pas la solution ultime pour protéger les données dans tous les cas de figure. Comme le précise cependant la XMPP Standards Foundation, cette étape devrait être suffisante pour couper court aux mécanismes passifs de capture des données. C’est d‘autant plus le cas que TLS doit être utilisé également pour les communications entre les serveurs.

 

La « promesse » demandée par la fondation était un manifeste dont la forme finale a été proposée en mars. Elle fait le constat qu’en dépit de la compatibilité avec SSL et TLS, ces deux protocoles ne sont pas utilisés de manière systématique. Elle donne donc une liste de points à respecter, dont :

  • L’utilisation de la méthode STARTTLS
  • L’utilisation, si possible, de la version 1.2 de TLS, mais en prévoyant une compatibilité descendante vers les versions 1.1 et 1.0, de même qu’avec SSLv3
  • Désactiver le support de SSLv2
  • La mise en place, si possible, de certificats pour les communications entre serveurs, afin que le chiffrement soit authentifié

Ceux qui souhaitent en savoir davantage sur la sécurité des services de messagerie basés sur XMPP pourront se rendre sur le site XMPP.net qui a mis en place un véritable observatoire sur la question. Le site distribue une note, sous la forme d'une lettre, le plus haut grade étant A. Pour l'obtenir avec une installation de Prosody sous Debian, il faut suivre ces recommandations (merci @Skhaen).

Une promesse relativement bien suivie 

Il est délicat de dire aujourd’hui qui utilise TLS et qui ne le fait pas. Le protocole est un standard que chacun peut utiliser librement, et la situation n’est donc pas comparable par exemple avec l’API Twitter, sur laquelle un contrôle strict s’exerce. Cependant, d’après l’annonce de la fondation plus de 70 développeurs et opérateurs de services ont répondu présent. Des noms connus y figurent d’ailleurs, tels que Jeremie Miller, créateur de Jabber, Thijs Alkemade, développeur en chef d’Adium (client multi-protocole sous OS X) ou encore George Hazan, créateur du client Miranda. La liste complète peut être consultée sur cette page.

 

Et ensuite ? Pour l’instant, le programme est flou. Dans la promesse, la XMPP Standards Foundation indique que le chiffrement des communications n’est qu’une « précondition » à l’arrivée « d’autres améliorations de la sécurité », sans préciser lesquelles. Elle donne toutefois quelques pistes en précisant que le chiffrement ne doit pas empêcher la mise en place de mesures complémentaires, telles que le chiffrement de bout en bout, l’authentification forte, la sécurisation des DNS ou encore la vérification des identités des serveurs.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

XMPP, un protocole largement utilisé 

Le début d'un effort généralisé de chiffrement des données 

TLS 1.2 est à préférer pour tous les échanges 

Une promesse relativement bien suivie 

next n'a pas de brief le week-end

Le Brief ne travaille pas le week-end.
C'est dur, mais c'est comme ça.
Allez donc dans une forêt lointaine,
Éloignez-vous de ce clavier pour une fois !

Fermer

Commentaires (15)


OTR est en train d’arriver au sein d’empathy:

https://bugs.freedesktop.org/show_bug.cgi?id=16891



Et cela grâce à un financement participatif.








Soriatane a écrit :



OTR est en train d’arriver au sein d’empathy:

https://bugs.freedesktop.org/show_bug.cgi?id=16891



Et cela grâce à un financement participatif.





Euh… c’est quoi cette “blague” ? La télépathie, vraiment ? <img data-src=" />



je crois plutot qu’ ils parlent de ca : Telepathy ou KDE Telepathy


Le très bon site xmpp.net donne une très bonne idée du niveau de sécurité du service xmpp aussi bien en c2s que s2s. Il test tout, tls dnssec dane etc…


Facebook va arrêter le support de XMPP en 2015?<img data-src=" />



<img data-src=" />








Soriatane a écrit :



OTR est en train d’arriver au sein d’empathy:

https://bugs.freedesktop.org/show_bug.cgi?id=16891



Et cela grâce à un financement participatif.







OTR est déjà présent dans Pidgin avec un plugin et nativement dans Jitsi. Dans Jitsi, il y a même ZRTP pour chiffrer l’audio et la vidéo.









Alucard63 a écrit :



Facebook va arrêter le support de XMPP en 2015?<img data-src=" />



<img data-src=" />





Oui, trop sécurisé. <img data-src=" />



Question bête:



Ces programmes ont beau être sécurisés à fond, mais quelle est la probabilité qu’il y ait des backdoors inclus?



Ça a beau être ouvert, mais au vu des millions de lignes de code, je suppose que personne ne verrait la présence d’une telle backdoor








js2082 a écrit :



Ça a beau être ouvert, mais au vu des millions de lignes de code, je suppose que personne ne verrait la présence d’une telle backdoor







Des millions ? Tout au plus des dizaines de milliers de lignes dans le code du serveur et idem dans le code du client. Lorsque le code est dispo, il n’y a aucun intérêt à introduire une backdoor, si c’est découvert c’est très risqué niveau image.









Max81 a écrit :



Des millions ? Tout au plus des dizaines de milliers de lignes dans le code du serveur et idem dans le code du client. Lorsque le code est dispo, il n’y a aucun intérêt à introduire une backdoor, si c’est découvert c’est très risqué niveau image.





Une faille de sécurité peut être une backdore (volontaire ou non) tant qu’elle n’est révélé publiquement… Une faille a beau être mauvais pour l’image d’une société ça n’en reste pas moins “fréquent”



au niveau serveur, prosody et metronome ont deux, trois ligne de conf a vérifier pour permettre le chiffrement.

Et pour éviter de faire râler les clients avec des certificats auto-signés, il y a un (des?)fournisseur de certificats gratuits qui prévoit un certificat web et un certificat xmpp.

au niveau clients, gajim (Linux/Windows), jappix (web), conversation (android) sont nativement prévu avec le chiffrement.








arno53 a écrit :



[quote:5030865:Max81]



Des millions ? Tout au plus des dizaines de milliers de lignes dans le code du serveur et idem dans le code du client. Lorsque le code est dispo, il n’y a aucun intérêt à introduire une backdoor, si c’est découvert c’est très risqué niveau image.





Une faille de sécurité peut être une backdore (volontaire ou non) tant qu’elle n’est révélé publiquement… Une faille a beau être mauvais pour l’image d’une société ça n’en reste pas moins “fréquent”[/quote]



Oui, une faille de sécu découverte mais non remontée, je veux bien y croire. Mais des backdoors volontaires sur des softs libres et de petite taille (un serveur xmpp c’est pas énorme, un client encore moins), j’y crois moins.









js2082 a écrit :



Question bête:



Ces programmes ont beau être sécurisés à fond, mais quelle est la probabilité qu’il y ait des backdoors inclus?



Ça a beau être ouvert, mais au vu des millions de lignes de code, je suppose que personne ne verrait la présence d’une telle backdoor







XMPP est un protocole, ouvert. Si tu n’a pas confiance dans les logiciels existants, il est toujours possible de créer le tien de toute pièce.



De même, le code de nombreux clients et serveur XMPP étant libre, rien n’empêche un audit par une organisation type ANSSI, association ou autre.









Max81 a écrit :



Oui, une faille de sécu découverte mais non remontée, je veux bien y croire. Mais des backdoors volontaires sur des softs libres et de petite taille (un serveur xmpp c’est pas énorme, un client encore moins), j’y crois moins.





Autant une backdoor volontaire peut avoir une forme du type if (user == NSA) then { champagne } un peu a la manière de ce qui se fait chez certain constructeur de routeur, autant quand tu as les moyens financier et d’ingenerie d’un etat je pense qu’il y’a moyen de contribuer a un projet open source, de faire du bon boulot pendant des mois/années puis glissé une “erreur” de codage qui réduit l’entropie de la fonction de chiffrement etc …



Le 22/05/2014 à 19h 09

Ah! Ça veut dire que le chiffrement est cassé pour de bon.



“Ils” ont les fameux ordinateurs quantiques. “Failles théoriques” dans les algorithmes de chiffrement courant?