Dans cette période de confinement due à l’épidémie de covid-19, la question de la communication sécurisée interpersonnelle ou de groupe pour maintenir les échanges professionnels se pose. Les fournisseurs grand public sont évidements hors jeux en terme de confidentialité d’une part à cause de la centralisation sur un serveur privé et d’autre part à cause de l’utilisation de protocoles propriétaires et de code source non libre. Sont donc exclus les solutions comme Skype ou Face Time. Le monde du libre offre des solutions bien plus intéressantes en terme de…. confidentialité et dont le maître mot est décentralisation !
Confidentialité
La question de la confidentialité est résolue par le chiffrement de bout en bout au-dessus de la couche applicative. Cela n’est évidement pas toujours possible pour des raison de performance (vidéo temps réelle) ou de commodité pour l’utilisateur. Ainsi je peux crypter mes mails avant de les envoyer, charge à mon destinataire de les déchiffrer. L’application peut fournir des facultés pour accomplir cette tâche supplémentaire avec un chiffrement intégré via OpenPGP ou encore plus simplement avec OMEMO qui ne requiert aucune compétence de la part de l’utilisateur pour s’assurer d’un chiffrement de bout en bout pour le protocole XMPP.
Décentralisation
Certaines solutions grand public propose un chiffrement entre le client et le serveur central mais rien ne garantie que le serveur central ne déchiffre pas le message avant de le transmettre au destinataire. C »est comme l’ouverture des colis par la Poste ! Le seul moyen de ce prémunir est le chiffrement de bout en bout pour garantir confidentialité et authenticité du message. Du moins momentanément.
En effet en passant par un serveur central que l’on ne maîtrise pas, les données chiffrées peuvent être stockées pour une analyse ultérieure. A moins que l’observateur ne scrute tout le réseau, on peut se prémunir simplement en utilisant un système de messagerie décentralisé dont chaque nœud est interopérable avec les autres. En allant au bout de l’idée héberger son propre nœud
Jitsi vidéo, audio et messagerie instannée
J’avais mis en place sur mon serveur personnel une instance de ejabberd qui me permet d’avoir mon propre système de messagerie instantanée sécurisé et interopérable. J’ai buté alors sur la mise en œuvre des fonctions audio et vidéo qui demandait trop d’effort d’intégration.
Jitsi est un logiciel open-source sous licence apache v2. Si originellement il était prévu pour la VoIP (audio) il est maintenant une solution de Visioconférence.
La version native s’installe comme un charme sur ma débian mais n’a pas fonctionné out of the box. Contrairement à la version dockerisée qui renforce ma conviction sur la conteneurisation: ça marche du premier coup ! En effet la partie configuration est déjà faite. Peut-être que mon problème avec la version native venait de mon infrastructure en NAT alors que avec docker l’application est forcément prévue dans une telle configuration. Dans le cas de Jitsi c’est en plus une agrégation de composants.
Out of the box
Pour rendre mon instance de Jitsi accessible depuis internet il ne m’a fallut que:
- créer un domaine pour ce service
- ajouter une redirection dans mon frontal apache pour ce domaine
- ouvrir les ports TCP et UDP pour RTP de ma box pour les envoyer vers mon serveur
- Restreindre les droits d’ouverture de conférence aux authentifiés en suivant la documentation
JItsi est orienté conférence et la messagerie instantanée est une fonction de groupe au sein d’une conférence. La solution ejabberd remplit bien son rôle mais dans le mouvement de changement et le confinement je testerai peut-être une solution plus moderne: Matrix !
Tags: jitsi