So funktioniert's
WebRTC Peer-to-Peer-Chat, erklärt
Nach dem Handshake steht kein Server mehr im Weg — es gibt also nichts zu speichern und nichts herauszugeben. Hier siehst du genau, was das Backend sieht, und die drei Dinge, die Peer-to-Peer dir nicht garantiert.
Peer-to-Peer-Raum öffnen
Peer-to-Peer-Raum öffnenDer Server macht nur die Vorstellung
Jede Chat-App, die du je genutzt hast, funktioniert im Kern gleich: Deine Nachricht geht hoch zum Server eines Unternehmens, der Server behält sie, und gibt sie dann an die andere Person weiter. Verschlüsselung entscheidet nur, wer diese Kopie lesen kann. Die Kopie existiert trotzdem.
Ein WebRTC-DataChannel überspringt genau diesen mittleren Schritt. Zwei Browser handeln eine direkte, verschlüsselte Verbindung aus, und sobald die steht, geht deine Nachricht ohne Umweg von deinem Gerät zu ihrem. FadeChats betreibt zwar einen Server, aber der arbeitet wie eine Telefonvermittlung: Er reicht den beiden Browsern die Details weiter, die sie brauchen, um sich zu finden, und ist danach aus dem Gespräch raus.
Das ist der ganze Trick, und deshalb gibt es auf dieser Seite keinen Button "Meine Daten löschen". Es gibt keine Nachrichtentabelle, aus der gelöscht werden müsste.
Was zwischen dem Öffnen der Seite und der ersten Nachricht passiert
- Dein Browser schreibt ein Angebot
Er baut ein SDP-Angebot, das den unterstützten Transport beschreibt, plus den Fingerabdruck eines Zertifikats, das er für diese Sitzung erzeugt hat. Das Angebot geht an den FadeChats-Server, geparkt unter einer zufälligen Raum-ID.
- Der andere Browser antwortet
Dein Gast öffnet den einmaligen Einladungslink, holt sich das Angebot ab und schickt eine Antwort zurück. Beide Seiten tauschen außerdem ICE-Kandidaten aus: die Netzwerkadressen, unter denen sie jeweils erreichbar sein könnten, ermittelt mit Hilfe eines STUN-Servers.
- Die beiden Enden geben sich direkt die Hand
ICE probiert Kandidatenpaare durch, bis eine Verbindung steht, dann führen die Browser darüber einen DTLS-Handshake. Sie leiten die Schlüssel selbst ab und prüfen sich gegenseitig anhand der Fingerabdrücke aus Schritt eins.
- Der Kanal öffnet sich, der Server ist fertig
Text, Bilder, GIFs und Sticker reisen über einen SCTP-Stream innerhalb dieser DTLS-Sitzung, Browser zu Browser. Die Setup-Datensätze laufen nach einer TTL von 10 Minuten ab, die durch Aktivität erneuert wird.
Wer was sehen kann
| Die eingeladene Person | Der FadeChats-Server | Ein TURN-Relay, falls nötig | |
|---|---|---|---|
| Nachrichten, Bilder, GIFs | Ja, das ist der Sinn | Nie | Nur verschlüsselte Bytes |
| Die Raum-ID | Ja | Ja | Ja |
| Deine IP-Adresse | Ja, bei direkter Verbindung | Ja, während des Setups | Ja, während des Relays |
| Dass der Raum aktiv war | Ja | Bis die TTL abläuft | Während des Relays |
| Irgendetwas, nachdem der Raum verblasst ist | Nur, was sie festgehalten hat | Es wurde nie etwas geschrieben | Nichts |
Dass beide Seiten die Adresse der anderen erfahren, liegt am Transportprotokoll selbst, nicht an einer Einstellung, die man abschalten könnte.
Drei Dinge, die Peer-to-Peer dir nicht garantiert
- Dein Gegenüber sieht deine IP-Adresse
Eine direkte Verbindung hat zwei echte Endpunkte, also erfährt die eingeladene Person ungefähr deine Stadt und deinen Provider. Signal verbirgt das, indem alles über die eigenen Server läuft. FadeChats kann das nicht, weil genau dieses Durchleiten alles ablehnt, was das Projekt eigentlich vermeiden will.
- Manchmal gibt es trotzdem ein Relay
Symmetrisches NAT, Firmennetzwerke und manche Mobilfunkanbieter blockieren einen direkten Pfad. WebRTC weicht dann auf ein TURN-Relay aus, das DTLS-verschlüsselte Bytes weiterleitet, zu denen es keinen Schlüssel besitzt. Trotzdem eine dritte Maschine im Weg, und das sollte man klar sagen.
- Der Handshake vertraut dem Signaling-Kanal
Jede Seite prüft den Zertifikats-Fingerabdruck der anderen, aber der Fingerabdruck kam über den Server. Ein kompromittierter Signaling-Server könnte ihn im Prinzip austauschen und sich dazwischenschalten. Signal löst das mit Sicherheitsnummern, die man außerhalb des Kanals vergleicht; FadeChats hat keine solche Prüfung.
Wofür dieses Modell passt
Peer-to-Peer ist richtig, wenn zwei Menschen etwas einmal sagen müssen und wollen, dass davon nirgendwo eine Kopie bleibt: ein Passwort mit einer Rückfrage, eine Adresse, eine Diagnose, eine Nummer. Für eine Gruppe ist es die falsche Form, genauso für alles, was einen geschlossenen Tab überstehen muss, und für Situationen, in denen ein Irrtum über den Gegenüber echte Konsequenzen hätte.
Häufig gestellte Fragen
Braucht ein WebRTC-Chat überhaupt einen Server?
Ja, aber nur, um die beiden Browser einander vorzustellen. Ein Signaling-Server überträgt das Angebot, die Antwort und die Netzwerk-Kandidaten; ein STUN-Server sagt jedem Browser, wie seine öffentliche Adresse aussieht. Sobald der DataChannel offen ist, steht keiner der beiden mehr zwischen einer einzigen Nachricht.
Kann der Signaling-Server meine Nachrichten lesen?
Nein, er bekommt sie nie zu sehen. Der Kanal wird zwischen den Browsern ausgehandelt, und die Schlüssel gehören ihnen. Der FadeChats-Server hält nur die Setup-Datensätze, und die laufen nach einer TTL von 10 Minuten ab, die durch Aktivität erneuert wird.
Sieht die andere Person meine IP-Adresse?
Bei einer direkten Verbindung ja, und du siehst umgekehrt auch ihre. Genau das macht sie direkt. Wenn das vor deinem Gesprächspartner verborgen bleiben soll, nutz ein VPN oder ein Tool, das alles durchleitet, wie Signal.
Ist ein WebRTC-DataChannel Ende-zu-Ende verschlüsselt?
Der Transport ist es: SCTP innerhalb von DTLS, mit Schlüsseln, die die beiden Browser selbst ableiten. Der Vorbehalt ist der oben beschriebene Austausch der Fingerabdrücke. Ende-zu-Ende-Verschlüsselung bei WebRTC ist nur so vertrauenswürdig wie der Kanal, über den diese Fingerabdrücke liefen.
Muss ich etwas installieren, um es auszuprobieren?
Nein. WebRTC steckt in jedem aktuellen Browser, FadeChats ist also einfach eine Seite, die du öffnest. Kein Konto, keine Telefonnummer, keine App. Der Raum entsteht, wenn die Seite lädt, und fasst genau zwei Personen.