Appels WebRTC/VoIP et exposition d’adresse IP

Registre de preuves — Phase 2

Ce dossier est une pièce de recherche datée. La conclusion canonique est celle du rapport final 1.0. Les synthèses antérieures et renvois à la Phase 3 restent historiques. UNKNOWN reste UNKNOWN.

Règle d’analyse : E2EE protège le contenu média, pas les adresses IP. Une ICE candidate publique/directe communiquée au pair peut lui révéler l’IP publique observable. TURN remplace la destination réseau vue par le pair par l’adresse du relais, mais le relais voit les connexions, les IP sources, les temps, volumes et généralement la durée; l’E2EE média limite ce qu’il peut écouter. STUN révèle l’adresse publique au serveur STUN pour la découverte, mais ne relaie pas à lui seul le média. VPN/Tor changent le point de sortie et déplacent la confiance; ils ne garantissent pas qu’aucune candidate directe ou locale ne soit divulguée sans test de la configuration.

Produit / mode vérifié dans la documentation	Le pair peut-il obtenir l’IP ?	Ce que le relais/opérateur peut apprendre	Limites de la preuve
Signal, appel 1:1	Le pair peut-il obtenir l’IP ?Selon la relation et le réglage : Signal affirme que les appels initiés par un non-contact sont toujours relayés; les autres peuvent être directs quand la connectivité le permet. « Always Relay Calls » force le relais.	Ce que le relais/opérateur peut apprendreRelais voit connexions et métadonnées réseau; E2EE protège le média.	Limites de la preuveDocumentation éditeur + réglage documenté par EFF; pas de capture réseau faite ici. Voir la fiche Signal ci-dessous.
SimpleX Chat	Le pair peut-il obtenir l’IP ?Non par défaut selon les docs actuelles : appels via TURN; désactiver « Always use relay » autorise P2P et peut exposer l’IP au contact.	Ce que le relais/opérateur peut apprendreLe serveur TURN prédéfini peut observer durée d’appel; serveur ICE peut voir les IP qui s’y connectent. Possibilité d’utiliser son propre relais ICE.	Limites de la preuveLa doc permet de changer la configuration; pas de vérification par capture sur versions mobile/desktop. Guide officiel des appels.
Session	Le pair peut-il obtenir l’IP ?Oui actuellement : appels WebRTC en beta, P2P; la FAQ dit explicitement que le pair et le STUN/TURN géré par STF reçoivent l’IP. Appels désactivés par défaut; pas d’appels de groupe; appels onion-routés annoncés comme futurs dans la FAQ.	Ce que le relais/opérateur peut apprendreLe service STUN/TURN voit l’IP et la session; la FAQ ne démontre pas l’étendue exacte des logs.	Limites de la preuveDéclaration fournisseur actuelle, pas de mesure indépendante. FAQ officielle, lignes Calls.
Olvid	Le pair peut-il obtenir l’IP ?Non selon la spécification 2024 : les SDP ne contiennent que des candidates TURN, ce qui masque l’IP du pair.	Ce que le relais/opérateur peut apprendreTURN reçoit les IP des deux côtés et voit métadonnées/durée; le serveur Olvid délivre les credentials TURN.	Limites de la preuveLa spec précise TURN sur tous les appels; doc admin plus récente annonce régions et possibilité de TURN alternatif sur Android. Pas de test des endpoints en production. Spec 2024, §39, FAQ administrateurs.
Threema 1:1	Le pair peut-il obtenir l’IP ?Oui si connexion directe possible; « Always relay calls » route via Threema pour masquer l’IP. L’éditeur indique que les IDs de vérification rouge sont relayés.	Ce que le relais/opérateur peut apprendreThreema/son TURN voit les IP quand appel relayé.	Limites de la preuveLa doc officielle limite la note P2P aux appels 1:1; groupe et versions doivent être vérifiés séparément. FAQ appels.
WhatsApp	Le pair peut-il obtenir l’IP ?Oui lorsque l’appel 1:1 est direct; activer « Protect IP address in calls » fait relayer tous les appels. Les appels de groupe sont relayés par défaut.	Ce que le relais/opérateur peut apprendreMeta/WhatsApp voit les IP et données réseau de ses relais, mais affirme que l’E2EE empêche l’écoute du média.	Limites de la preuveDocumentation Meta et Help Center, pas mesure indépendante. Engineering Meta, Help Center.
Telegram 1:1	Le pair peut-il obtenir l’IP ?Oui si P2P autorisé; le réglage P2P désactivé force le relais Telegram pour ne pas révéler l’IP au contact.	Ce que le relais/opérateur peut apprendreTelegram reçoit les connexions/routage; le relais voit IP et timing.	Limites de la preuveAPI officielle documente P2P et reflectors; chaîne de traduction officielle décrit le réglage. API appels, texte de réglage.
Wire 1:1 / conférence	Le pair peut-il obtenir l’IP ?1:1 : oui quand ICE choisit un flux direct; sinon TURN. Conférence : composant SFT/relay.	Ce que le relais/opérateur peut apprendreLe whitepaper dit que les TURN sont séparés du backend, sans user-ID selon la conception Wire; le TURN voit nécessairement les IP/temps/volume.	Limites de la preuveSource éditeur, whitepaper §Calling; proposition de séparation non vérifiée indépendamment. Whitepaper PDF, pp. 24–28.
Delta Chat	Le pair peut-il obtenir l’IP ?Oui quand ICE établit une connexion directe, selon la politique officielle.	Ce que le relais/opérateur peut apprendreLa politique dit que le relais d’appel voit les IP des deux participants même quand le média est direct; fallback turn.delta.chat possible si le chatmail n’intègre pas de relais.	Limites de la preuveDoc/politique fournisseur; implémentation et configuration relay du contact peuvent varier. Privacy Policy, architecture d’appel.
Element / Matrix	Le pair peut-il obtenir l’IP ?Non établi uniformément. Element Call actuel utilise une SFU/LiveKit; les services et le fournisseur voient l’IP, et l’E2EE du média est annoncé. Les anciens appels Matrix/WebRTC et installations auto-hébergées dépendent de la config STUN/TURN et client.	Ce que le relais/opérateur peut apprendreLa politique Element dit que Element traite IP, Matrix ID, device ID, timestamp et type d’appel; pour call.element.io, LiveKit Cloud est utilisé. Un homeserver auto-hébergé change l’opérateur, pas le fait que le SFU/STUN voit des IP.	Limites de la preuvePas de capture réseau cliente; ne pas généraliser le nouveau Element Call aux appels historiques. Privacy policy, §Element Call et Push, Element Call/SFU docs.
XMPP + OMEMO	Le pair peut-il obtenir l’IP ?Possiblement oui : Jingle/ICE peut négocier des candidates directes; TURN peut masquer le pair.	Ce que le relais/opérateur peut apprendreJID/serveur, STUN/TURN et opérateur du client dépendent du déploiement.	Limites de la preuvePas d’application cible choisie : conclusion protocolaire, pas comportement universel. XEP-0166 Jingle.
Jami / Tox-qTox	Le pair peut-il obtenir l’IP ?Probablement oui en appels P2P directs; exactes candidates et réglages par client/réseau non établis ici.	Ce que le relais/opérateur peut apprendreDHT/nœuds bootstrap, peer et éventuels relais voient des éléments différents; logs/config exacts inconnus.	Limites de la preuveÀ vérifier par docs/version et capture en laboratoire avant verdict.
Briar / Cwtch / Ricochet Refresh	Le pair peut-il obtenir l’IP ?Appels temps réel : non documentés comme fonctionnalité actuelle dans les sources examinées; ne pas supposer qu’ils en ont.	Ce que le relais/opérateur peut apprendre—	Limites de la preuveÀ confirmer par documentation des releases actuelles.

Conséquence provisoire pour le cas principal

Si masquer l’IP au correspondant est une exigence ferme et que des appels sont nécessaires, les preuves documentaires actuelles favorisent un réglage explicite de relais : Olvid documente TURN-only; SimpleX utilise TURN par défaut; Signal, Threema, WhatsApp et Telegram ont un réglage de relais; Delta Chat et Wire peuvent établir du P2P; Session expose explicitement l’IP du pair dans ses appels actuels. Cela ne constitue pas un classement général : le relais échange l’exposition au correspondant contre une exposition au relais, et la qualité/configuration doit encore être testée.