OSINT d’infrastructure — limite de la collecte actuelle¶
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.
Les sources documentaires officielles décrivent les rôles d’infrastructure de tous les produits, mais les observations DNS courantes restent échantillonnées. Des réponses A/AAAA/CNAME et des préfixes BGP/ASN sont maintenant consignés pour des endpoints Matrix/Element, Signal, certains presets SimpleX, Wire, Jami, Olvid et deux endpoints Delta Chat. Pour Olvid, l’attribution régionale des IP AWS a été recoupée avec le fichier IP ranges du fournisseur et a révélé une discordance avec deux étiquettes de région TURN publiées. Pour Threema, les sources consultées donnent des ports et emplacements déclarés, mais pas les hostnames d’API nécessaires à une attribution réseau défendable. Pour les autres services, une carte DNS/ASN complète reste à acquérir. Les résolutions faites ici sont des requêtes DNS actives ordinaires, pas des historiques DNS passifs; elles ne révèlent pas à elles seules le propriétaire contractuel, les origins, les régions de données, les logs ou le trafic réellement utilisé. Aucun scan de port ni connexion applicative n’a été effectué. La première tentative standard avait reçu un accès réseau refusé; les requêtes ciblées ultérieures ont été autorisées.
Couverture OSINT par service — observation et inconnues séparées¶
Cette table est un index de ce qui a effectivement été observé dans les dossiers ci-dessous, pas une cartographie exhaustive ni une attribution de propriété. « Snapshot » signifie résolution DNS ordinaire et consultation publique de BGP/ASN à une date donnée; ce n’est pas du passive DNS historique et cela ne prouve ni la localisation des données ni la route prise par un client donné.
| Service | Architecture / endpoints publics utiles | Observation DNS / ASN consignée | Inconnu qui demeure |
|---|---|---|---|
| Signal | Service central; noms officiels de connectivité et appels, dont signal.org, sfu.voip.signal.org et turn3.voip.signal.org. Domaines et ports |
signal.org → Cloudflare AS13335; SFU → Google Cloud AS396982; turn3 a répondu NODATA au résolveur testé. RIPEstat AS13335, AS396982 |
API de messagerie, origines, région SFU, autres pools TURN, routage réellement utilisé et journaux. |
| SimpleX | Réseau de relais SMP sélectionnables; presets officiels et relais ICE/TURN séparés. Vue d’ensemble [accès à vérifier] | Snapshots de certains relais: smp11 AS400226 (StormyCloud), smp12 et smp14 AS63949 (Linode/Akamai); échantillon de presets uniquement. RIPEstat AS400226, AS63949 |
Inventaire complet et changeant des relais/ICE, domaine client réellement choisi, opérateur contractuel et rétention par nœud. |
| Olvid | Serveur de compte/routage, transfert, pièces jointes et régions TURN documentés par le fournisseur. FAQ administrateurs | Snapshots des noms TURN et comparaison aux plages AWS; deux étiquettes régionales publiées ne concordaient pas avec les network border groups AWS observés. Plages AWS | Répéter depuis d’autres régions/résolveurs; confirmer auprès du fournisseur; ne pas inférer région de stockage, opérateur contractuel ou politique de logs. |
| Session | Messages via Session Network/onion requests; appels beta avec STUN/TURN STF selon FAQ. FAQ | Pas de snapshot DNS/ASN complet des services courants dans cette passe. | Nœuds de sortie/entrée réellement choisis, adresse source visible par chaque nœud, endpoints d’appel et rétention. |
| Threema | Services centraux, directory/identity, push, appels et transfert selon documentation; l’API courante n’est pas entièrement nommée dans le corpus. Rapport de transparence | Aucun mapping défendable des domaines de production. Une bibliothèque tierce cite api.threema.ch/identity, mais la résolution n’a pas abouti ici; ce n’est pas une preuve d’API active. |
Hostnames officiels actuels, domaines par fonctionnalité, DNS/ASN, hébergeurs, régions et sous-traitants. |
| Cwtch | Architecture Tor et services onion plutôt que serveur central classique. Documentation | Pas de DNS/ASN applicatif attribué dans cette passe. | Inventaire des services onion/relays utilisés par build, bootstrap, opérateurs et dépendances de téléchargement. |
| Briar | Pas de serveur central de messages; Tor sur Internet et transports locaux Bluetooth/Wi-Fi/carte mémoire. Architecture | Pas de mapping DNS/ASN des chemins de production consigné. | Relais Tor réellement utilisés, bootstrap/bridges selon build, endpoints de téléchargement et disponibilité par pays. |
| Jami | DHT, bootstrap, proxy/TURN et service de noms documentés dans le code et les dossiers. Code Jami | Snapshots des endpoints échantillonnés principalement attribués à OVH AS16276; une adresse n’a pas été résolue/attribuée. RIPEstat AS16276 | Ensemble de nœuds, rotation, opérateur de chaque service, configuration par client et éventuels relais tiers. |
| Tox / qTox | DHT distribué avec nœuds bootstrap; le client et le protocole n’ont pas d’infrastructure centrale de comptes. c-toxcore | Pas de snapshot complet des nœuds bootstrap, IP/ASN ou de leur disponibilité consigné. | Liste/version des nodes utilisés, changements de bootstrap, observation DHT et éventuels relais de fichiers/appels. |
| Matrix / Element | Homeserver choisi (Matrix.org ou autre), services Element Call/SFU et push distincts. Element Call | matrix.org, vector.im et endpoint d’appel observés derrière Cloudflare AS13335; SFU/JWT rattachés à AWS eu-central-1 dans l’échantillon. |
Routes par région/utilisateur, fédération réellement utilisée, autres homeservers, storage/CDN et sous-traitants. |
| XMPP / OMEMO | Architecture dépend du domaine et de l’hébergeur choisis; le serveur conversations.im est une option, pas le réseau entier. Hébergement Conversations |
Aucun domaine d’instance choisi n’a été résolu/attribué dans cette passe. | Il faut fixer client, domaine, serveur upload, push gateway, DNS/ASN et juridiction; aucune généralisation au protocole. |
| Telegram | Service central avec points d’accès/API et stockage cloud; Secret Chats ont une portée distincte. FAQ | Pas de snapshot DNS/ASN actuel consigné pour ce dossier. | Domaines/API par région, CDN/media, anycast, hébergement effectif et routage de compte. |
| Service central Meta, avec push, média et chemins d’appels; déclaration d’infrastructure générale uniquement. Privacy policy | Aucun snapshot DNS/ASN de production consigné. | Domaines WhatsApp vs Meta, cloud/CDN/origins, régions, partenaires et routes par fonctionnalité. | |
| Discord | API, messages/fichiers centralisés; migration Cloudflare annoncée pour une partie des appels audio/vidéo. Annonce Discord | Pas de DNS/ASN observé; l’annonce d’ingénierie sur Cloudflare concerne voice/video, pas l’API texte ou stockage. | Domaines/API, régions, ASNs et fournisseur de données pour texte, médias et services d’identité. |
| Wire | Backend central et pools séparés de TURN/SFT selon whitepaper et dossiers. Whitepaper | Endpoints échantillonnés, notamment pools d’appels, attribués à Amazon AS16509; une entrée n’a pas de préfixe attribuable. RIPEstat AS16509 | Mapping complet des endpoints backend, régimes régionaux, contrat cloud, routage effectif et logs. |
| Delta Chat | Email choisi par l’utilisateur, chatmail optionnel, push et relais d’appel/fallback Delta. Politique | nine.testrun.org et turn.delta.chat observés sur Hetzner AS24940. RIPEstat AS24940 |
Les serveurs choisis par chaque utilisateur, relais tiers, régions et trafic réel; deux endpoints ne cartographient pas l’écosystème. |
| Ricochet Refresh | Messages via Tor onion services; site, dépôt et distribution binaire restent des dépendances séparées. Dépôt | Pas de snapshot DNS/ASN du site/download ou des services Tor consigné. | DNS/registrar/CDN du site, signatures de releases, bootstrap Tor, relais et miroir de distribution. |
| Status / Waku | Nœuds Waku gérés et services Store/Bootstrap/Filter/Light Push, proxy RPC et push documentés par Status. Infrastructure Status [accès à vérifier] | Pas de snapshot DNS/ASN pour les nœuds utilisés par Status App. | Endpoint réel par session, concentration d’opérateurs, régions/clouds, logs, IP/topics et push. |
Limite de méthode : les ASN nomment un réseau annonçant le préfixe au moment observé, pas nécessairement le fournisseur de service ou le propriétaire du serveur. CDN, anycast, reverse proxy et hébergement loué peuvent séparer annonce réseau, opérateur applicatif et détenteur contractuel. Les observations ne remplacent pas une capture réseau contrôlée sur client/version identifiés.