Comment fonctionne Jami (anciennement Ring.cx) et comment est-il sécurisé?
Jamis'appelle lui-même "confidentialité et contrôle ultimes pour vos communications vocales, vidéo et de chat". Mais les forums en ligne ont mentionné au passage (peu de profondeur) qu'il utilise de mauvais protocoles de cryptographie et a un code source salissant. Qu'est-ce qui n'est pas sûr de son architecture et pourquoi ces aspects sont-ils problématiques?
Il ne semble pas qu'ils offrent une sécurité avancée parfaite pour les conversations vocales ou de chat. ... Ils n'utilisent pas de protocole comme OTR ou Axolotl conçu pour les communications en temps réel. ... Leur description de leur cryptage confirme mes inquiétudes. Ils n'utilisent pas de protocole comme ZRTP pour empêcher les attaques MITM. (lien)
... d'autres logiciels, tels que WhatsApp, Ring, ChatSecure et Signal ne sont pas sécurisés que vous ne le pensez. ... "Ring" utilise SIP, qui est très ancien et non compatible P2P. Ils l'ont revendiqué comme un logiciel "décentralisé", et ce sont des taureaux ***. (lien)
Ring, d'autre part, semble vouloir utiliser des "normes établies", qui sont pleines de failles qui éliminent la sécurité.
Cela ne reflète pas la réalité des protocoles sécurisés, et les experts en sécurité réels considèrent généralement la "sécurité de bricolage" comme dangereuse et s'appuient sur des primitives ou même des protocoles établis. (lien)
Salutations, développeur Ring ici. Ring est une plateforme de communication distribuée, ses nœuds font partie d'un réseau DHT, donc leur IP est en effet exposée. (lien)
Ils prennent en charge la cryptographie qui est considérée comme endommagée. https://en.wikipedia.org/wiki/POODLE Ils corrigent également leur librairie crypto - il y a quelque chose de profondément faux si vous devez patcher la librairie crypto que vous utilisez .. Et non, il ne s'agit pas des correctifs eux-mêmes, mais de "à quel point votre bibliothèque de cryptographie est-elle cassée, de sorte que vous devez la corriger?" - ring-daemon @ 8ca874d790be92649187aabcb55fa998dae045df J'examinerais plus les choses, mais plus j'aurais l'air pire. Pas du tout comparable à Tox.
(…) Il adopte une approche légèrement différente de celle de Tox en s'appuyant non seulement sur des bibliothèques cryptographiques établies, mais également sur des protocoles établis. Si cela suffit (comme il est fait pour apparaître) pour le rendre sage sur le plan de la sécurité ... eh bien, pour le dire simplement, ce n'est pas suffisant.
N'est-ce pas construit sur des choses cassées? À savoir, TLS/SSL. ... C'est une question de complexité - plus quelque chose est complexe à travailler, plus il y aura de bugs en conséquence. Utiliser quelque chose d'aussi complexe que TLS/SSL aide vraiment à avoir un code crypto bogué. IMO quoi que ce soit utilisant SSL/TLS va être cassé, que ce soit tôt ou tard. L'une des raisons pour lesquelles Tox utilise NaCl/libsodium. (lien)
En tant que développeur Jami (anciennement Ring), j'essaierai de répondre à cette question. Bien sûr, cette réponse est inévitablement biaisée et incomplète, mais elle pourrait répondre à certaines préoccupations ou malentendus sur le fonctionnement de Jami, et aider à comprendre son architecture et les limites de cette architecture.
La construction d'une plate-forme de communication distribuée en temps réel sécurisée est souvent un compromis entre facilité d'utilisation, performances et confidentialité. Le modèle de sécurité de Jami n'est pas parfait et évoluera probablement, et nous sommes ouverts aux commentaires, suggestions et critiques. J'essaierai de modifier cette réponse pour ajouter plus de détails si demandé.
Il ne semble pas qu'ils offrent une sécurité avancée parfaite pour les conversations vocales ou de chat. ... Ils n'utilisent pas de protocole comme OTR ou Axolotl conçu pour les communications en temps réel. ... Leur description de leur cryptage confirme mes inquiétudes. Ils n'utilisent pas de protocole comme ZRTP pour empêcher les attaques MITM.
Jami établit une session TLS 1.3 authentifiée d'égal à égal (à l'aide de GnuTLS) avec des suites de chiffrement PFS appliquées, généralement (TLS1.3) ECDHE-SECP384R1) - (RSA-PSS-RSAE-SHA384) - (AES-256- GCM) est utilisé.
Ce canal TLS authentifié P2P est utilisé pour SIP signalisation, et les clés de chiffrement temporaires des supports SRTP sont négociées avec SIP sur ce canal. Cela signifie que les communications en temps réel sur Jami (audio et vidéo) sont cryptés PFS et de bout en bout, mais Jami n'offre pas d'autres garanties comme la répudiation.
Dans le SIP "classique" (basé sur serveur), la négociation des clés de média dans SIP est un problème car SIP peuvent voir ces clés en texte brut, rompant cryptage de bout en bout et autoriser les attaques MITM. C'est ce que ZRTP résout, en effectuant l'échange de clés DH sur le canal RTP (média). Utilisation de SIP on un canal P2P authentifié rend l'utilisation de ZRTP inutile.
"Ring" utilise le protocole SIP, qui est très ancien et non compatible P2P.
Le protocole SIP peut être utilisé pour le P2P très bien, de la même manière que l'on peut utiliser HTTP pour les communications P2P, et c'est un protocole de téléphonie établi et robuste, même s'il n'est pas parfait et que certaines personnes préférez XMPP ou autres.
Ils l'ont revendiqué comme un logiciel "décentralisé", et ce sont des taureaux ***.
Jami est entièrement distribué, ce qui est --- (plus fort que décentralisé , en utilisant OpenDHT (une table de hachage distribuée Kademlia similaire à celle utilisée par Bittorrent) pour trouver les adresses IP des contacts, qui sont stockées sur le DHT sous la forme de crypté [[# #]] glace [~ # ~] candidats, utilisé pour établir le canal TLS P2P authentifié. Les noms d'utilisateurs (nom <-> mappages de clés publiques) sont enregistrés sur une blockchain distribuée (contrat Ethereum). À ma connaissance, aucun autre système de communication en temps réel n'offre ce niveau de distribution.
Développeur Ring ici. Ring est une plateforme de communication distribuée, ses nœuds font partie d'un réseau DHT, donc leurs IP sont en effet exposées.
C'est un inconvénient de l'utilisation d'un réseau distribué: les adresses IP des nœuds DHT sont exposées sur le réseau distribué, ce qui constitue un problème de confidentialité valide. La conception actuelle ne permet pas de lier cryptographiquement les nœuds DHT aux clés publiques Jami et nous travaillons pour rendre cette séparation aussi forte que possible.
Ils corrigent également leur bibliothèque de crypto - il y a quelque chose de très grave si vous devez patcher la bibliothèque de crypto que vous utilisez ..
N'est-ce pas construit sur des choses cassées? À savoir, TLS/SSL. ... C'est une question de complexité - plus quelque chose est complexe à travailler, plus il y aura de bugs en conséquence. Utiliser quelque chose d'aussi complexe que TLS/SSL aide vraiment à avoir un code crypto bogué. IMO quoi que ce soit utilisant SSL/TLS va être cassé, que ce soit tôt ou tard. L'une des raisons pour lesquelles Tox utilise NaCl/libsodium.
(commentaire ci-dessus fait par un développeur Tox)
Nous ne "corrigeons pas notre librairie cryptographique"; lorsqu'un bug ou une vulnérabilité est trouvé, la bibliothèque est mise à jour.
Nous vivons dans le monde réel où aucune bibliothèque de crypto (et aucune bibliothèque en général) n'est parfaite. Avec le temps, chaque crypto finit par être brisé - ce n'est pas une prédiction mais une observation.
La complexité de TLS est un inconvénient, mais un avantage est la capacité de négocier des cyphersuites, donc quand une cyphersuite commence à être considérée comme faible, la transition vers de nouvelles cyphersuites peut se faire avec élégance, sans casser les implémentations existantes.
Libsodium (NaCL) est une bibliothèque de grande qualité, mais n'est pas directement comparable à TLS. NaCL fournit des blocs de construction cryptographiques élémentaires, tandis que TLS est un protocole qui effectue tout: authentification, échange de clés, chiffrement, etc. d'une manière standard et très bien examinée.
Lors de la construction de Jami, nous avons essayé de ne pas réinventer la roue autant que possible, pour éviter le risque d'ajouter des vulnérabilités. Au lieu de construire notre propre protocole à l'aide de libsodium, nous avons préféré nous baser sur TLS et nous sommes concentrés sur son utilisation de la meilleure façon possible.
aberaud dit:
Ring établit une session DTLS 1.2 peer-to-peer authentifiée (à l'aide de GnuTLS) avec des suites de chiffrement PFS appliquées, généralement TLS_ECDHE_RSA_AES_256_GCM_SHA384 est utilisé.
Ce canal TLS authentifié P2P est utilisé pour SIP signalisation, et les clés de chiffrement temporaires des supports SRTP sont négociées avec SIP sur ce canal. Cela signifie que les communications en temps réel sur Ring (audio et vidéo) sont cryptés PFS et de bout en bout. Cependant, Ring n'offre pas d'autres garanties comme la non-répudiation.
La partie "les communications sur Ring (audio et vidéo) sont PFS" est vraie selon ce que vous dites être PFS. De la conversation à la suivante, c'est-à-dire entre deux établissements de connexion ultérieurs (échanges de clés), les communications sont en effet parfaitement sécurisées vers l'avant ET vers l'arrière . Cependant, au cours d'une même conversation où plusieurs messages sont échangés, chaque message suivant est crypté à l'aide d'une même clé.
Par conséquent, les messages d'une même conversation ne sont pas échangés de manière sécurisée ni sécurisée vers l'arrière.
Pour obtenir une communication PFS et BS au cours d'une même conversation, quelque chose comme OTR, Axolotl doit en effet être utilisé, mais ce n'est pas directement mieux adapté à l'audio/vidéo, mais plutôt plus pour les messages texte. Si nous limitons la question au cryptage audio/vidéo, SCIMP (l'un des cliquets d'Axolotl) peut être utilisé pour effectuer des communications PFS (mais pas BS) au cours d'une même conversation. Concernant l'échange de messages dans un groupe, Ring devrait utiliser quelque chose comme GOTR , mpOTR ou même Axolotl avec 1-to-1 des canaux sécurisés entre tout le monde. Bien qu'Axolotl ne gère pas les problèmes de groupe par lui-même et GOTR a été conçu pour surpasser mpOTR. Par conséquent, GOTR pourrait être le mieux adapté. Il convient de mentionner que l'équipe de développeurs Ring étudie actuellement ces situations depuis le début de l'année.
Voici un peu plus une raison pour laquelle ring.cx n'est pas particulièrement sécurisé (en fait, il fonctionne à peine correctement).
La sécurité repose en grande partie sur les vecteurs d'attaque et la réduction du nombre dans votre système. Vous ne réduirez jamais cela à zéro, probablement parce que vous devez toujours faire confiance à quelque chose, et la confiance en celle-ci peut être déplacée (l'autre utilisateur auquel vous vous connectez transfère tout ce que vous dites de leurs haut-parleurs à quelqu'un d'autre, par exemple), mais l'idée avec sécurité, c'est dire que vos vecteurs sont petits et peu, contre grands et nombreux, et pouvoir préparer des contre-mesures spécifiques contre ceux que vous connaissez (et peut-être ceux que vous ne connaissez pas).
La raison pour laquelle les gens disent que le code source désordonné est un problème est double.
- En cas de manque d'ordre, il est très facile de masquer les bogues, et tout bogue est une exploitation potentielle. Bien sûr, aucun programme, même celui qui a l'air sympa, n'est entièrement exempt de bogues (sauf preuve contraire d'une vérification mathématique de la sécurité du son), mais celui qui est en désordre est susceptible de contenir de très nombreux bogues, pointeurs nuls, etc.
- L'équipe a toujours du mal à faire fonctionner correctement les clients du programme et le programme plante toujours régulièrement, rencontre des erreurs et manque de fonctionnalité.
- Un coup d'œil rapide sur le code source ne montre aucun test pour aucun des clients.
- La plupart du code est écrit en C Plus Plus - ce n'est pas que cette langue ne peut pas être sécurisée, mais c'est une langue connue pour les débordements de pile, les erreurs de pointeur, les débordements de mémoire, etc. Il existe de meilleures langues telles que Rust ou même Go, qui offrent des protections plus basiques contre ce genre de problèmes.
- Le style du code est radicalement différent entre les projets clients. Je ne dis pas que les styles ne peuvent pas être différents, mais cela trahit le fait que des développeurs très différents avec des compétences et des normes de codage différentes contribuent, et il n'y a pas de gardien compétent pour dire `` non, ce code ne répond pas à nos normes'
- Le système de construction est trop compliqué et plein de problèmes potentiels. Bien que vous puissiez avoir une impression particulière sur l'un ou l'autre système de construction, celui-ci utilise jusqu'à 5 ou 6 - python, cmake, autotools, bash, g ++, VC++. Cela signifie qu'il serait plus facile d'injecter une dépendance illégitime dans la construction elle-même, et augmente les risques de vandalisme du projet, uniquement par les chiffres.
- Il attire un grand nombre de dépendances externes, qui peuvent elles-mêmes être de qualité douteuse. Cela a du sens, mais cela signifie également qu'ils n'ont pas développé et testé leurs propres bibliothèques pour, par exemple. décodage/encodage vidéo, leur qualité et leur sécurité sont aussi bonnes que leurs bibliothèques tierces. De nombreuses vulnérabilités de sécurité Linux antérieures ont dû faire face à des bibliothèques obscures avec une capacité obscure ayant un bogue exploitable qui a transformé un système autrement sécurisé en un POC (Pile Of Crap) non sécurisé.
- Développement fragmenté sans direction claire, ni instruction
- Le client n'est pas un client, mais 6. Il y a 2 clients Windows, 2 clients mobiles, 1 client linux (bien qu'il puisse y en avoir 2, ce qui porte à confusion, le site indique qu'il y a un gnome et un client kde linux), et un Electron/Web client. Il n'y a pas de code commun entre ces clients (sans tenir compte de ring-lrc et ring-daemon), et bien que l'équipe soutienne qu'il s'agit d'un meilleur `` design '' pour ne pas contraindre une plate-forme particulière, cela signifie qu'ils ne peuvent pas faire une bonne garantie de sécurité sur leur plate-forme comme s'ils prenaient en charge 3 clients, par exemple Android, IOS, bureau.
- Ils utilisent plusieurs bibliothèques non complémentaires dans leur code. Dans la même application Linux, ils utilisent GTK + QT, qui offrent tous deux la même fonctionnalité et sont des boîtes à outils indépendantes sans compatibilité prise en charge. Il s'agit d'une source potentielle majeure de bogues. Il n'y a pas grand-chose à faire au sujet de l'incompatibilité fondamentale entre Android et IOS (on pourrait dire qu'une seule plate-forme mobile matérielle serait plus sécurisée - s'ils sont bien conçus, bien sûr.) Les clients Windows sont une partie de l'application QT + GTK et un client de la plateforme Windows universelle.
- Au moment d'écrire ces lignes, il n'y a qu'une page wiki décrivant comment construire le projet. Il n'y a aucune indication, même sur une architecture générale de base, sur la façon dont les clients devraient parler à la bibliothèque cliente ou au démon, ni sur la façon de corriger les bogues ou d'implémenter de nouvelles fonctionnalités. Cela signifie qu'il sera très difficile pour tout nouveau développeur de prendre non seulement une décision raisonnable sur la façon de mettre en œuvre quelque chose, mais aussi une décision qui finira par être une décision sûre.
Du point de vue de l'algorithme d'implémentation de la mise en réseau/sécurité, certaines des bibliothèques qu'elles utilisent peuvent en effet être non sécurisées, obsolètes ou simplement cassées. Ce qui précède devrait être une bibliothèque assez convaincante que le travail le plus difficile, le travail au niveau de la sécurité du réseau, n'est pas meilleur, et probablement dans un état de choses pire, que la couche d'interface utilisateur client.
Certaines des idées, telles que les algorithmes DHT ou double rachet, peuvent être de bonnes idées de sécurité et peuvent même avoir des primitives sécurisées disponibles, mais c'est pourquoi je ne considérerais pas cette application comme la plus sûre. Si je ne peux pas compter sur le client pour faire la bonne chose, qui veut dire qu'il ne sera pas détourné par un processus utilisateur non privilégié sur le bureau, et toute garantie de sécurité valide faite par la bibliothèque de mise en réseau aura alors disparu? Ou s'ils utilisent une ancienne bibliothèque de réseau non sécurisée, qu'il n'y a aucun moyen d'activer certaines fonctionnalités et donc de vaincre l'utilisation de l'algorithme sécurisé?
Cela étant dit, c'est un projet intéressant si vous voulez simplement explorer le multimédia sur de nombreuses plates-formes, en mettant l'accent sur les algorithmes de sécurité comme une sorte de projet de "recherche", mais est-il mis en œuvre en toute sécurité? Assurément non.
Ce n'est pas si facile de répondre à cette question. Pas à cause de ce service, mais comme une affirmation générale.
Un service comme celui-ci peut être aussi sécurisé que possible en utilisant et en implémentant la cryptographie de manière appropriée. Mais cela comprend plusieurs choses:
- Utilisation de systèmes cryptographiques connus et "sécurisés"
- Utilisation de bibliothèques et de systèmes correctement audités
- Maintenir tout audité, patché et mis à jour
- Et enfin, implémentez, codez et déployez correctement toutes ces parties ensemble
Mais le plus important de tous, maintenir cette structure en sécurité au quotidien.
En échouant dans l'un de ces points, cela réduira l'état de sécurité de tout service.
Peut-être que demain, une faille d'implémentation dans l'une des bibliothèques utilisées sera découverte, et c'est presque "impossible" à éviter.
Ce n'est pas réaliste de faire une affirmation comme marquer un service comme sécurisé ou non sécurisé uniquement sur la base de quelques faits techniques, la sécurité est un tout :)