Serveur et Open Source

---

Olvid utilise-t-elle un serveur ?

Olvid s’appuie sur un serveur afin de permettre une transmission asynchrone efficace des messages. Concrètement, cela permet à un message d’être « mis en attente » jusqu’à ce que le destinataire ait de la connexion. Le message lui est alors immédiatement envoyé et est ensuite supprimé de notre serveur. Dans la majeure partie des cas, le message est supprimé quasiment immédiatement après avoir été reçu.

Cette architecture présente-t-elle un risque en termes de sécurité ?

Il est important de noter que Olvid chiffre l’intégralité des communications de bout-en-bout. Les messages, en particulier, sont donc chiffrés sur le téléphone de l’envoyeur, pour n’être déchiffrés que sur le téléphone du destinataire. Ils restent intégralement chiffrés pendant leur transit d’un téléphone à l’autre. Le chiffrement mis en œuvre par Olvid concerne l’intégralité des données et métadonnées, à l’exception de la clé publique du destinataire (ce qui est le strict minimum pour permettre au serveur de « router » efficacement les messages vers le bon destinataire). Notez que la clé publique de l’envoyeur n’apparaît pas dans le message envoyé, toutefois, son adresse IP est visible par le serveur (comme pour n’importe quel service sur internet via TCP/IP). Olvid fonctionnera très bien derrière un VPN ou via Tor si vous souhaitez masquer cette dernière.

Les protocoles cryptographiques mis en œuvre par Olvid ont été conçus dans un modèle de sécurité exigeant. En particulier, les garanties de confidentialité doivent être maintenues y compris dans la situation où le serveur d’Olvid serait contrôlé par un adversaire. Pour dire les choses simplement : lorsque vous communiquez avec Olvid, vous n’avez pas à faire confiance au serveur par lequel transitent les messages. Même dans la situation où il serait malveillant, les garanties de sécurité d’Olvid sont maintenues.

Peer-to-peer vs. serveur de distribution centralisé

Certaines messageries instantanées ont fait le choix de décentraliser la distribution des messages. Cette décentralisation n’apporte pas une sécurité comparable à un chiffrement à l’état de l’art, et doit donc toujours être accompagnée d’un chiffrement de bout-en-bout. En revanche, une décentralisation de la distribution peut garantir une certaine résilience aux pannes ou aux dénis de service. Mais ceci s’accompagne généralement d’une expérience utilisateur dégradée (latence pour recevoir les messages, bande passante limitée).

Olvid en multi-serveurs

Aujourd’hui, Olvid utilise un seul serveur pour relayer les messages. Ceci dit, l’architecture actuelle a déjà été conçue de façon à pouvoir supporter plusieurs serveurs (un peu à l’image du mail). S’il ne s’agit pas de peer-to-peer, à terme, chaque groupe d’utilisateurs pourra avoir son propre serveur.

Nous réévaluons aussi régulièrement les possibilités vers une architecture multicloud.

Le code du serveur est-il open source ?

L’intégralité du code des clients est open-source. Ce code, une fois compilé, permet de produire des clients iOS et Android qui pourront communiquer avec notre serveur en production (le même que celui utilisé par les applications clients téléchargées sur l’App Store ou Google Play), et donc d’entrer en relation et de discuter avec tous les autres utilisateurs d’Olvid.

Pour le moment, nous avons néanmoins choisi de ne pas publier le code source du serveur par lequel transitent les messages et ce, pour quatre raisons :

Le modèle de sécurité d’Olvid vous protège de son serveur

Pour les raisons données ci-dessus, le serveur d’Olvid ne joue aucun rôle dans la sécurité des communications. Cet aspect distingue Olvid de l’immense majorité des autres messageries chiffrées de bout-en-bout, qui s’appuient généralement sur un « tiers de confiance » pour permettre aux utilisateurs d’entrer facilement en communication les uns avec les autres. Ce tiers peut prendre plusieurs formes, les plus classiques étant une blockchain ou un annuaire centralisé permettant à l’opérateur de la solution d’associer une donnée privée de l’utilisateur (numéro de téléphone, adresse email, etc.) à son identité numérique. Ce tiers de confiance intervient alors à chaque début d’interaction entre deux utilisateurs et son rôle est de garantir l’intégrité de l’échange de leurs identités numériques. Si ce tiers est malveillant, c’est la sécurité de toute l’architecture qui est mise à mal.

Toute messagerie qui aurait fait le choix de centraliser la sécurité au sein d’un annuaire unique qu’elle contrôle a donc intérêt à en publier le code.

Le cas d’Olvid est différent : nous avons fait le choix de ne jamais imposer un tiers de confiance unique à nos utilisateurs, considérant que cela représenterait un risque trop important en termes de sécurité. Par ailleurs, cela permet à Olvid de fonctionner sans avoir à demander/connaître la moindre donnée personnelle sur ses utilisateurs. Rendre le code open source n’aurait pas d’impact sur la sécurité. Ce qui protège les utilisateurs d’Olvid, ce sont les protocoles cryptographiques mis en œuvre, intégralement publiés (et donc auditables) dans les codes sources des applications clientes iOS et Android.

Le code source actuel est aussi en grande partie de la configuration AWS

Le serveur de distribution de messages d’Olvid est aujourd’hui hébergé par AWS. Nous utilisons une architecture entièrement serverless qui nous a notamment permis de garantir une excellente qualité de service jusqu’à aujourd’hui. Cette architecture permet à nos équipes techniques de libérer du temps pour développer les applications clientes (au sein desquelles se situe l’intelligence d’Olvid) plutôt que de passer du temps en administration serveurs (un sujet particulièrement complexe et chronophage).

Si cette architecture est parfaitement adaptée dans le cadre d’une messagerie grand public pouvant servir plusieurs centaines de milliers d’utilisateurs (voir plus), elle n’est clairement pas pratique pour déployer un serveur « personnel » dont l’objectif est de n’en servir que quelques centaines. Le code source du serveur actuel ne serait donc pas très utile pour celles et ceux qui désirent déployer leur propre serveur.

Le serveur d’Olvid est en évolution permanente

Olvid propose régulièrement de nouvelles fonctionnalités. Il est alors important de permettre aux utilisateurs ayant mis à jour l’application de pouvoir en profiter au plus vite, sans pour autant les empêcher de communiquer avec leurs contacts qui n’ont pas encore mis à jour. Le serveur joue un rôle important dans ce mécanisme, en étant capable de gérer aussi les anciennes versions de l’application. À noter : le serveur Olvid actuel est encore utilisable avec les premières versions publiques d’Olvid (sorties à l’été 2019).

En pratique, lorsque de nouvelles fonctionnalités sont développées dans Olvid, le serveur est mis à jour avant la publication de ces mises à jour sur les stores. Si ce n’était pas le cas, l’application pourrait ne plus être fonctionnelle. L’API du serveur est donc en évolution permanente. Tant qu’elle n’est pas stabilisée, nous ne pouvons pas encourager nos utilisateurs à gérer leur propre serveur puisqu’ils pourraient perdre l’usage d’Olvid à chaque mise à jour des apps. Pire, tous leurs contacts pourraient être impactés, donnant alors l’impression que c’est l’application qui ne fonctionne pas.

Le risque de déni de service

Comme nous l’avons expliqué, le serveur de distribution des messages d’Olvid ne joue aucun rôle dans la sécurité. En revanche, il est central pour la qualité de service. Il est donc important de le protéger au mieux contre les dénis de service, ou autres attaques sur la disponibilité.

Ouvrir le code du serveur présente alors un risque important, car il donnerait à des personnes mal intentionnées tous les outils nécessaires pour cibler au mieux leurs attaques contre ces serveurs.

Sera-t’il open source un jour ?

Oui, quand les API seront stabilisées et que nous serons prêts. Mais pour toutes les raisons expliquées précédemment, ça ne sera probablement pas la version AWS que nous ouvrirons, mais plutôt une version « standalone » (par exemple un Docker), facile à déployer et plus adaptée pour un « petit » nombre d’utilisateurs (quelques centaines).

Vers une architecture multicloud

Nous réévaluons régulièrement les possibilités afin d’être en mesure de proposer une offre infrastructure et serveurs multicloud. Notre objectif est de privilégier, quand cela sera possible, des solutions labélisées SecNumCloud (ou une qualification européenne d’un niveau au moins équivalent).