Comment ça marche

Le chat WebRTC peer-to-peer, expliqué

Une fois la négociation terminée, il n'y a plus aucun serveur sur le chemin : rien à stocker, rien à transmettre à qui que ce soit. Voici exactement ce que voit le backend, et les trois choses que le peer-to-peer ne vous offre pas.

Ouvrir un salon P2P

Le serveur ne fait que les présentations

Toutes les applications de chat que vous avez utilisées fonctionnent de la même façon en coulisses : votre message monte vers le serveur d'une entreprise, le serveur le conserve, puis le transmet à l'autre personne. Les débats sur le chiffrement portent sur qui peut lire cette copie. La copie, elle, existe toujours.

Un DataChannel WebRTC saute cette étape intermédiaire. Deux navigateurs négocient une connexion chiffrée directe, et une fois qu'elle est ouverte, votre message va de votre machine à la sienne sans rien entre les deux. FadeChats fait bien tourner un serveur, mais il agit comme un standardiste : il transmet aux deux navigateurs ce dont ils ont besoin pour se trouver, puis il sort de la conversation.

C'est toute l'astuce, et c'est pourquoi ce site n'a pas de bouton « supprimer mes données ». Il n'y a pas de table de messages dans laquelle supprimer quoi que ce soit.

Deux personnes debout sous un lampadaire discutant à un coin de rue la nuit
La signalisation, c'est quelqu'un qui vous indique l'un à l'autre. Après ça, il n'y a plus que vous deux.Pexels · .M.Q Huang

Ce qui se passe entre l'ouverture de la page et le premier message

  1. Votre navigateur rédige une offre

    Il construit une offre SDP décrivant le transport qu'il prend en charge, ainsi que l'empreinte d'un certificat généré pour cette session. L'offre part vers le serveur de FadeChats, stationnée sous un identifiant de salon aléatoire.

  2. L'autre navigateur répond

    Votre invité ouvre le lien d'invitation à usage unique, récupère l'offre et renvoie une réponse. Les deux côtés échangent aussi des candidats ICE : les adresses réseau où chacun pourrait être joignable, découvertes avec l'aide d'un serveur STUN.

  3. Les deux extrémités se serrent la main directement

    ICE teste des paires de candidats jusqu'à ce qu'une connexion s'établisse, puis les navigateurs effectuent une négociation DTLS par-dessus. Ils dérivent eux-mêmes les clés et se vérifient mutuellement par rapport aux empreintes engagées à la première étape.

  4. Le canal s'ouvre, le serveur a fini son travail

    Texte, images, GIFs et stickers voyagent sur un flux SCTP à l'intérieur de cette session DTLS, de navigateur à navigateur. Les enregistrements de configuration expirent au bout d'un TTL de 10 minutes, renouvelé par l'activité.

Qui voit quoi

La personne que vous avez invitéeLe serveur de FadeChatsUn relais TURN, si nécessaire
Messages, images, GIFsOui, c'est le butJamaisUniquement des octets chiffrés
L'identifiant du salonOuiOuiOui
Votre adresse IPOui, sur une connexion directeOui, pendant la mise en placeOui, pendant le relais
Que le salon était actifOuiJusqu'à l'expiration du TTLPendant le relais
Après la disparition du salonSeulement ce qu'elle a capturéRien n'a jamais été écritRien

Que chaque côté apprenne l'adresse de l'autre est une propriété du transport, pas un réglage que vous pouvez désactiver.

Une personne tapant sur un ordinateur portable près d'une fenêtre la nuit, le visage éclairé par l'écran
Une ligne directe fonctionne dans les deux sens : la personne que vous avez invitée peut voir d'où viennent vos paquets.Pexels · VAZHNIK

Trois choses que le peer-to-peer ne vous offre pas

  • Votre interlocuteur voit votre adresse IP

    Une connexion directe a deux extrémités bien réelles, donc la personne que vous avez invitée apprend approximativement votre ville et votre fournisseur d'accès. Signal cache cela en relayant tout via ses propres serveurs. FadeChats ne le peut pas, parce que tout relayer est justement ce qu'il refuse de faire.

  • Parfois, il y a un relais quand même

    Le NAT symétrique, les réseaux d'entreprise et certains opérateurs mobiles bloquent le chemin direct. WebRTC se rabat alors sur un relais TURN, qui transmet des octets chiffrés en DTLS dont il ne détient aucune clé. Cela reste une troisième machine dans le trajet, et ça mérite d'être dit clairement.

  • La négociation fait confiance au canal de signalisation

    Chaque côté vérifie l'empreinte du certificat de l'autre, mais cette empreinte est arrivée via le serveur. Un serveur de signalisation compromis pourrait en principe la substituer et se placer au milieu. Signal résout cela avec des numéros de sécurité que vous comparez par un autre canal ; FadeChats n'a pas ce genre de vérification.

Où ce modèle a du sens

Le peer-to-peer est la bonne solution quand deux personnes doivent se dire quelque chose une seule fois et ne veulent qu'aucune copie n'existe nulle part : un mot de passe avec une question de suivi, une adresse, un diagnostic, un numéro. C'est le mauvais modèle pour un groupe, pour tout ce qui doit survivre à la fermeture d'un onglet, et pour une situation où se tromper sur son adversaire a des conséquences réelles.

Questions fréquentes

Un chat WebRTC a-t-il vraiment besoin d'un serveur ?

Oui, mais seulement pour présenter les deux navigateurs l'un à l'autre. Un serveur de signalisation transporte l'offre, la réponse et les candidats réseau ; un serveur STUN indique à chaque navigateur à quoi ressemble son adresse publique. Une fois le DataChannel ouvert, aucun des deux ne se trouve sur le chemin du moindre message.

Le serveur de signalisation peut-il lire mes messages ?

Non, il ne les reçoit jamais. Le canal est négocié entre les navigateurs et les clés leur appartiennent. Le serveur de FadeChats ne conserve que les enregistrements de configuration, qui expirent au bout d'un TTL de 10 minutes renouvelé par l'activité.

L'autre personne voit-elle mon adresse IP ?

Sur une connexion directe, oui, et vous voyez la sienne aussi. C'est ce qui la rend directe. Si vous devez la cacher à la personne avec qui vous parlez, utilisez un VPN, ou un outil qui relaie tout, comme Signal.

Un DataChannel WebRTC est-il chiffré de bout en bout ?

Le transport, oui : SCTP à l'intérieur de DTLS, avec des clés que les deux navigateurs dérivent eux-mêmes. La réserve, c'est l'échange d'empreintes évoqué plus haut. Le chiffrement de bout en bout de WebRTC n'est fiable qu'à hauteur du canal qui a transporté ces empreintes.

Faut-il installer quelque chose pour essayer ?

Non. WebRTC est intégré à tous les navigateurs actuels, donc FadeChats n'est qu'une page à ouvrir. Aucun compte, aucun numéro de téléphone, aucune application. Le salon existe dès que la page se charge et accueille deux personnes.