Découverte des nœuds et relais chiffré multisaut

Les nœuds AeroNyx se découvrent mutuellement au moyen de descripteurs signés à durée limitée et peuvent transmettre saut par saut des charges utiles chiffrées de bout en bout, chaque relais ne retirant que sa propre couche de chiffrement. Aujourd'hui, la messagerie réelle des utilisateurs passe par défaut par le relais central AeroNyx (RelayWS). L'acheminement de la messagerie via les nœuds est un réglage facultatif, à activer dans l'application.

Ce qui fonctionne aujourd'hui

Les chemins centralisés et décentralisés fonctionnent côte à côte.

Fonctionnement de la découverte

Chaque nœud publie un descripteur signé avec sa clé d'identité Ed25519. Un descripteur comprend l'identifiant du nœud, les heures d'émission et d'expiration, un point de terminaison public facultatif, des indicateurs de capacités (par exemple relais intermédiaire en oignon ou relais de messagerie), des indications approximatives de capacité et la clé utilisée pour le chiffrement en oignon. Les nœuds rejettent les descripteurs expirés ou dont la signature n'est pas valide.

• La diffusion est bornée. L'échange entre pairs est limité en débit et soumis à une politique, et les messages ont des limites de taille.
• Reprise après redémarrage. Un nœud conserve un cache local de pairs et se replie sur les points de terminaison d'amorçage configurés après un redémarrage. Les opérateurs peuvent aussi épingler des amorces (voir la section sur les amorces épinglées).
• Sélection des routes. Seuls les descripteurs récents disposant d'un point de terminaison utilisable et d'une clé d'oignon sont retenus comme candidats relais.

Quels points de terminaison un descripteur peut désigner

Une signature prouve qui a publié un descripteur, et non que son point de terminaison peut être contacté sans risque. Un nœud n'accepte donc que deux formes de point de terminaison :

• une adresse IP publique en http ou https ; les plages de bouclage, privées, lien-local, CGNAT, de documentation, de multidiffusion et réservées sont rejetées ;
• une URL https:// avec un nom DNS public. Les noms à un seul label, localhost et les suffixes privés tels que .local, .internal et .home.arpa sont rejetés.

Les noms d'hôte sont résolus au moment de la connexion par un résolveur qui écarte toute adresse non publique, de sorte qu'un nom ne puisse pas pointer vers le nœud lui-même, vers un réseau privé ou vers un service de métadonnées cloud. Les clients pairs ignorent également les paramètres de proxy et ne suivent jamais les redirections.

La forme par nom d'hôte existe pour que des nœuds ne disposant pas de leur propre adresse IP, comme un nœud TEE situé derrière une passerelle cloud, puissent participer.

Amorces épinglées

Un nœud qui démarre sans instantané fourni par l'opérateur ne fait confiance qu'aux identités qu'il détient déjà, et peut donc finir par ne faire confiance qu'à lui-même. Dans ce cas, un opérateur peut désigner l'identité attendue à une adresse :

[discovery]
pinned_seeds = ["<64-hex node id>@<public ip>:<port>"]

• Une identité épinglée n'est acceptée pour la première fois qu'après un échange par TLS lié à l'identité, épinglé sur cette identité.
• Chaque descripteur ultérieur d'une identité épinglée, quelle qu'en soit la source, doit conserver l'adresse épinglée et annoncer le TLS lié à l'identité.
• La confiance ne se transmet pas : les autres descripteurs présents dans la réponse d'une amorce restent des candidats non fiables.
• Une épingle supprimée ne peut pas revenir depuis un ancien cache ou une ancienne sauvegarde.

La Directory Chain

Chaque nœud conserve également un historique signé et chaîné par hachage des événements de son propre descripteur, appelé sa Directory Chain. D'autres nœuds peuvent dupliquer cet historique, récupérer des objets descripteurs et demander des preuves d'inclusion pour un descripteur donné. Des pairs épinglés par l'opérateur peuvent signer des points de contrôle d'observation portant sur les historiques qu'ils ont vus.

Il n'existe ni registre global ni coordinateur unique : chaque nœud signe son propre historique, et les autres le dupliquent et le vérifient.

TLS lié à l'identité

Joindre un nœud en HTTPS exige normalement un nom de domaine et un certificat délivré par une autorité de certification, alors que la plupart des nœuds AeroNyx ne sont joignables que par leur adresse IP. À la place, un nœud prouve lui-même son point de terminaison HTTPS grâce à son identité Ed25519.

• Fonctionnement. Le nœud crée une clé TLS ECDSA P-256 ordinaire et un certificat auto-signé. Un nom alternatif du sujet porte une liaison, aeronyx-tls-binding:v1:<node id>:<expiry>:<signature>, où la signature est produite par la clé d'identité du nœud sur un condensat à séparation de domaine de la clé publique du certificat lui-même, de l'identifiant du nœud et de l'expiration. La négociation TLS 1.3 prouve que le nœud détient la clé du certificat. La clé d'identité ne signe jamais une négociation.
• Ce que vérifie un client. Un vérificateur n'accepte un certificat que pour le nœud qu'il voulait joindre : exactement une liaison, l'identifiant de nœud attendu, non expirée, au plus 31 jours de validité restante, et une signature valide sur la clé de ce certificat. Un certificat délivré par une autorité de certification ne satisfait pas cette vérification.
• Même port. Le port public de l'API (8422/TCP) sert les deux : une connexion qui commence par une négociation TLS reçoit du TLS, et tout le reste reçoit du HTTP en clair comme auparavant. Cette fonction est activée par défaut (discovery.public_api_identity_tls).
• Entre nœuds. Un nœud dont le descripteur signé annonce la fonctionnalité de protocole anpf1-ibt1 sert du TLS lié à l'identité. Un pair qui voit cette fonctionnalité doit joindre ce nœud par TLS épinglé sur son identité et ne se replie jamais sur du HTTP en clair. La fonctionnalité est couverte par la signature du descripteur : un attaquant réseau ne peut donc pas la retirer pour forcer une rétrogradation. Si plusieurs identités revendiquent le même point de terminaison, aucune adresse TLS n'est produite et la requête échoue sans repli. Les nœuds plus anciens sans cette fonctionnalité, ainsi que les points de terminaison de passerelle nommés par DNS, conservent leur comportement précédent.
• Référence. Code source et vecteurs de test figés : aeronyx-node-tls.

Il en résulte que les informations de route des sauts en oignon, la diffusion entre pairs, la synchronisation de l'annuaire et le trafic de témoins entre les nœuds ne sont plus lisibles sur le réseau. La prise en charge, dans l'application, de la connexion aux nœuds de cette manière est en cours de développement.

Fonctionnement du relais multisaut

1. L'expéditeur enveloppe la charge utile dans une couche de chiffrement par saut, en utilisant la clé d'oignon publiée de chaque relais.
2. Chaque relais vérifie la signature, l'horodatage et l'état anti-rejeu du saut précédent, retire sa propre couche et transmet le bloc opaque restant. Il ne voit jamais les couches internes.
3. Le nœud final (terminal) remet le message à la boîte de réception du relais du destinataire (le relais central par défaut) et, seulement après que le relais l'a accepté, renvoie un accusé de réception signé. L'accusé de réception lie l'identifiant de route, un engagement sur la charge utile, l'identité du nœud terminal et l'heure de remise. Il prouve que le message a été accepté en garde par le relais, et non que le destinataire l'a lu. Un nœud dont la remise est désactivée conserve le message dans son propre stockage et signe le même type d'accusé de réception : l'accusé seul ne permet donc pas de distinguer les deux cas.

Ce que voit chaque partie

Aucun nœud pris isolément ne relie votre adresse réseau à la personne à qui vous écrivez. Le nœud terminal et le relais central voient tous deux qui a écrit à qui.

Le protocole accepte au plus trois sauts de relais vérifiés. La route de confidentialité de l'application en utilise deux. Les limites anti-abus des relais sont décrites dans Protection anti-abus du relais aveugle.

La messagerie dans l'application

• Par défaut : les messages passent par le service central RelayWS. Le contenu des messages est chiffré de bout en bout, mais le service traite les métadonnées de remise. Consultez Intégration client du relais de messagerie.
• Route de confidentialité (facultative, désactivée par défaut) : lorsqu'elle est activée et qu'une route est prête, l'application envoie d'abord les messages individuels par la route en oignon à deux sauts. Si aucune route en oignon n'accepte le message, l'application le conserve sur l'appareil et n'utilise pas le relais standard, sauf si vous l'approuvez pour ce message.
• Boîte aux lettres anonyme (bêta) : un dépôt distinct qui ne fonctionne que pendant la connexion au réseau de confidentialité. Les conversations ordinaires ne l'utilisent pas.

Tailles de récupération de la boîte aux lettres anonyme

Le résultat d'une récupération de boîte aux lettres était auparavant une image fixe de 163 130 octets quel que soit l'élément : un court message coûtait donc une réponse d'environ 160 Kio. La version 2 de la récupération, négociée par la fonctionnalité de protocole signée anpf1-ampc1, complète l'élément scellé jusqu'à la plus petite de cinq classes de taille (4 204, 16 492, 65 644 ou 131 180 octets, ou le maximum du codec). Un élément de 4 096 octets circule désormais sous la forme de 4 518 octets.

Nœud TEE

Un nœud de production s'exécute dans un environnement d'exécution de confiance Phala Cloud (dstack sur Intel TDX). Il sert uniquement de boîte aux lettres anonyme et de relais en oignon : son VPN est désactivé, MemChain est désactivé, et sa clé d'identité provient du service de clés dstack. Il n'est joignable que par un nom d'hôte TLS sur la passerelle, ce qui explique l'ajout des points de terminaison par nom d'hôte. L'application ne vérifie pas actuellement l'attestation TEE du nœud.

État en direct

L'état agrégé du réseau est publié à l'adresse :

GET https://api.aeronyx.network/api/privacy_network/vpn/public/network-stats/

Les agrégats relatifs au relais et à la découverte apparaissent sous data.protocol_status, par exemple peer_store.blind_relay et peer_store.peer_quorum. Notez deux points lors de leur lecture :

• Les agrégats par nœud ne comptent que les nœuds ayant émis un signal de présence au cours des 120 dernières secondes : un nœud hors ligne disparaît donc de décomptes tels que protocol_status.reported_nodes. network.total_nodes et network.vpn_nodes comptent toujours les nœuds actifs enregistrés, qu'ils soient en ligne ou non.
• Les compteurs de sondes synthétiques (probe_*, two_hop_probe_*) mesurent la santé des chemins. Ils ne correspondent pas à du trafic utilisateur.

La réponse publique ne contient que des décomptes, des catégories d'état et des horodatages. Elle n'inclut jamais d'identifiants de nœuds, de points de terminaison, d'identifiants de routes, de charges utiles, de destinataires, d'adresses IP de clients, de données DNS ni de liens du graphe social. Consultez Statistiques du réseau et frontière de confidentialité.

Questions fréquentes

Mes messages AeroNyx passent-ils par des nœuds décentralisés ?

Pas par défaut. Les messages passent par le service central RelayWS. Vous pouvez activer la route de confidentialité dans l'application : elle envoie alors les messages individuels par une route en oignon à deux sauts via les nœuds lorsqu'une route est prête. Si aucune route n'accepte un message, l'application le conserve jusqu'à ce qu'une route soit disponible ou que vous approuviez l'envoi de ce message par le relais standard.

Un nœud relais peut-il lire les messages qu'il transmet ?

Non. Un relais ne retire que sa propre couche de chiffrement et transmet un bloc opaque. Le contenu des messages est en outre chiffré de bout en bout entre les participants à la conversation.

Qu'est-ce que la Directory Chain ?

La Directory Chain est l'historique signé et chaîné par hachage des descripteurs propre à chaque nœud. D'autres nœuds la dupliquent et peuvent demander des preuves d'inclusion. Elle n'a pas de coordinateur global.

Comment un nœud situé derrière une passerelle peut-il rejoindre le réseau ?

Il peut publier un nom d'hôte https:// comme point de terminaison. Les autres nœuds résolvent ce nom au moment de la connexion et n'utilisent que des adresses publiques, de sorte que le nom ne peut pas être redirigé vers des cibles privées ou internes.

Pourquoi la page de statistiques publiques affiche-t-elle plus de nœuds enregistrés que de nœuds en ligne ?

network.total_nodes et network.vpn_nodes comptent les nœuds actifs enregistrés, qu'ils soient en ligne ou non. Comparez-les avec network.online_vpn_nodes. Les décomptes de protocole et de transfert n'incluent que les nœuds dont le signal de présence est récent.

Les nœuds ont-ils besoin d'un nom de domaine ou d'une autorité de certification pour le HTTPS ?

Non. Un nœud peut prouver son point de terminaison HTTPS avec sa propre clé d'identité : son certificat TLS porte une signature de l'identité du nœud sur la clé du certificat, et un client ou un pair qui connaît l'identifiant du nœud peut la vérifier. Les nœuds situés derrière une passerelle peuvent toujours utiliser à la place un nom d'hôte https://.

Que prouve un accusé de réception de remise signé ?

Il prouve que le nœud terminal a accepté le message en garde par le relais, en pratique dans la boîte de réception du relais du destinataire. Il ne prouve pas que le destinataire a vu ou lu le message. Pour cela, utilisez les accusés de remise et de lecture du protocole de messagerie.