Un appel sécurisé comporte plusieurs chemins de données. La signalisation coordonne qui appelle et comment les terminaux se connectent ; le chemin des médias transporte l’audio et la vidéo. Protéger un chemin ne protège pas automatiquement l’autre, et aucun des deux ne masque à lui seul tous les schémas de communication.
WebRTC fournit des mécanismes de sécurité importants, mais les contrôles d’identité de l’application, les rôles des serveurs et le mode d’enregistrement déterminent toujours la frontière complète de confidentialité.
Signalisation et médias remplissent des rôles différents
| Couche | Fonction habituelle | Question de sécurité |
|---|---|---|
| Signalisation | Invitations, descriptions de session et candidats de connexion | Qui peut lire ou modifier les informations d’établissement, et comment l’interlocuteur prévu est-il authentifié ? |
| Médias | Audio, vidéo et flux temps réel associés | Où se termine le chiffrement, et quels terminaux peuvent accéder aux médias ? |
| Enregistrements opérationnels | Routage, horaires de connexion et état de livraison | Quelles métadonnées le service ou le réseau peut-il observer ? |
| Enregistrement | Production d’une copie conservée | Qui reçoit le texte en clair ou des clés d’enregistrement utilisables, et où la copie est-elle stockée ? |
Un protocole de messagerie peut transporter une signalisation chiffrée, mais WebRTC n’exige pas universellement le format d’enveloppe d’une messagerie particulière. D’autres conceptions authentifiées sont possibles.
Ce que fournit DTLS-SRTP
L’architecture de sécurité WebRTC, RFC 8827, exige la protection des canaux de médias et décrit l’établissement des clés DTLS-SRTP. Pour simplifier, DTLS contribue à établir le contexte cryptographique et SRTP protège les paquets de médias en temps réel.
Les extrémités de cette protection comptent. Une connexion chiffrée directe entre participants diffère d’une connexion qui se termine sur un serveur de traitement des médias. Certains systèmes multipartites ajoutent une couche distincte de bout en bout au-dessus du chiffrement de transport vers le serveur. Le mot « WebRTC » seul ne dit pas quelle architecture utilise un produit.
Pourquoi l’authentification de la signalisation compte
L’établissement d’un appel peut contenir des informations servant à lier la connexion des médias au correspondant prévu. Si un attaquant peut remplacer ces informations sans être détecté, le chiffrement peut établir une connexion protégée vers le mauvais terminal.
La RFC 8827 aborde cette relation entre signalisation, identités et empreintes DTLS. HTTPS protège une connexion au service de signalisation ; il ne dispense pas, à lui seul, de prendre en compte un service malveillant ou compromis. Une signalisation authentifiée de bout en bout ou un mécanisme indépendant approprié de vérification du correspondant peut renforcer cette frontière.
La confidentialité de la signalisation est un objectif lié, mais différent : elle limite qui peut lire les détails de l’établissement. Une conception doit expliquer à la fois confidentialité et authentification, plutôt que de considérer un bloc chiffré comme une preuve suffisante de chacune.
Une signalisation chiffrée ne rend pas un appel invisible
Le relais peut toujours savoir entre quels comptes ou appareils il assure le routage. Des observateurs du réseau peuvent voir les horaires de connexion, le volume du trafic et les adresses des serveurs. Les correspondants ou l’infrastructure de relais peuvent aussi apprendre des informations réseau selon la conception de la connexion.
Par conséquent, chiffrer une invitation d’appel ne prouve pas que le service ne peut pas déduire l’existence d’un appel, cartographier des relations ou conserver des données liées aux appels. Masquer le contenu et masquer les schémas de trafic sont deux problèmes distincts.
La frontière publiée par Livara
La page de sécurité de Livara décrit les appels directs et de groupe comme chiffrés de bout en bout, mais formule une exception explicite pour l’enregistrement serveur facultatif : tant que l’état visible REC est actif, l’appel utilise le chiffrement de transport plutôt que l’E2EE.
Son modèle de menace rejette également les promesses d’anonymat des métadonnées et de protection contre un appareil compromis. Ce sont des déclarations du produit, pas une vérification indépendante de chaque chemin d’appel. Ce guide n’affirme aucune limite de participants, aucun format de signalisation ni aucune implémentation postquantique des médias qui n’aient été vérifiés.
En particulier, un échange de clés postquantique de la messagerie ne met pas automatiquement à niveau une négociation distincte des médias WebRTC. Les algorithmes et la liaison des clés sur le chemin des médias doivent être évalués indépendamment.
Avant un appel sensible
- Confirmez les participants et examinez les changements d’identité inattendus.
- Vérifiez si l’enregistrement est activé et ce que l’application indique que cela change.
- Comprenez si le service traite les médias ou se contente de transmettre des paquets protégés.
- Prenez en compte les appareils et les pièces autour des participants : un logiciel malveillant, une capture d’écran ou une personne à proximité qui écoute peut exposer le contenu après déchiffrement.
- Demandez des preuves d’architecture et de tests pour le mode exact utilisé, plutôt que de vous fier à une mention générale « appels chiffrés ».
Une affirmation de sécurité utile identifie séparément qui peut accéder à la signalisation, aux médias, aux métadonnées et aux enregistrements.
