Wie eine private Verbindung entsteht
Vom Moment, in dem Sie ein Meeting erstellen, bis zum laufenden, verschlüsselten Gespräch — jeder Schritt in klarer Sprache, mit den tieferen Details für technisch Interessierte.
Das große Ganze
Sie erstellen ein Meeting
Ihr Browser erzeugt einen zufälligen Meeting-Namen und einen geheimen Schlüssel. Der Schlüssel wird ans Ende des Links gehängt, hinter das „#“ — der einzige Teil einer Webadresse, den Browser nie an einen Server senden.
Sie laden jemanden ein
Sie teilen den Link. Zum Öffnen braucht es weder App noch Konto. Weil der Schlüssel im Link steckt, kann nur lesen, wem Sie den Link schicken.
Ihre Geräte verbinden sich direkt
Die beiden Browser finden einander und öffnen einen direkten, verschlüsselten Kanal. Ab dann laufen Nachrichten, Dateien und Anrufe direkt zwischen Ihnen — nicht über uns.
Der Schlüssel liegt im Link, nicht auf unseren Servern
Verschlüsselungsschlüssel verwandeln lesbaren Text in unleserliche Daten und wieder zurück. In den meisten Apps behält der Anbieter eine Kopie dieser Schlüssel. Hier wird der Schlüssel auf Ihrem eigenen Gerät erzeugt und in den Teil des Links gelegt, der hinter dem „#“ steht — bekannt als URL-Fragment.
Browser behandeln dieses Fragment als rein lokal: Es landet nie in der Anfrage, die zu einem Server reist. Das Geheimnis, das Ihr Gespräch entschlüsselt, erreicht uns also nie. Wir könnten Ihre Nachrichten nicht lesen, selbst wenn wir dazu gezwungen würden.
Das Fragment wird vollständig im Browser gelesen und daraus ein symmetrischer Schlüssel abgeleitet. Da es nie im Anfragepfad, in Parametern oder Headern auftaucht, fehlt es in Zugriffsprotokollen, im Server-Arbeitsspeicher und bei jeder Zwischenstation. Der Besitz des Links ist die Berechtigung; „Entziehen“ bedeutet, das Meeting stillzulegen, nicht ein bei uns liegendes Geheimnis zu wechseln.
Das eigentliche Problem: zwei Fremde, die einander nicht sehen
Zuerst gilt es, ein Problem zu lösen. Ihre beiden Geräte sitzen meist hinter Heim- oder Büroroutern, die sich eine einzige öffentliche Adresse teilen und unaufgeforderten eingehenden Verkehr abweisen. Keines der Geräte kennt einen funktionierenden Weg zum anderen.
Irgendetwas muss sie einander vorstellen — ohne je das Gespräch selbst zu sehen.
Das ist das klassische NAT-Problem. Die meisten Geräte leben hinter Network Address Translation, die viele private Adressen auf eine gemeinsame öffentliche Adresse abbildet und nur Rückverkehr für selbst gestartete Verbindungen durchlässt. Zwei solche Geräte können einander nicht einfach „anrufen“; sie brauchen einen abgestimmten Prozess aus Entdeckung und Durchstoßen.
Signaling: die Vorstellung (der Handshake)
Um die beiden Geräte einander vorzustellen, schreibt jedes eine kurze Notiz: wie es erreichbar ist und was es unterstützt — welche Arten von Audio, Video und Daten es verarbeiten kann. Diese Notizen werden über ein winziges Relais hin- und hergereicht, das wir genau dafür betreiben: eine Notiz an die Gegenseite geben und die Antwort zurückbringen.
Dieser Schritt heißt Signaling. Die Notizen enthalten ausschließlich Verbindungsdetails — niemals den Inhalt Ihres Gesprächs — und werden in dem Moment verworfen, in dem die Verbindung steht.
Jede Seite erzeugt eine Sitzungsbeschreibung: ein „Offer“ vom Initiator und ein „Answer“ von der Gegenseite, die Medienfähigkeiten und Transportparameter auflisten. Sie werden über einen minimalen Signaling-Kanal ausgetauscht — eine Seite legt ihre Beschreibung ab, die andere liest sie und antwortet. Dieser Austausch ist kurzlebig und nur im Arbeitsspeicher; er sieht nie den verschlüsselten Strom, der danach folgt.
WebRTC: wie Browser direkt miteinander sprechen
All das läuft über WebRTC — einen Standard, der in jedem modernen Browser eingebaut ist und es zweien erlaubt, eine direkte Leitung für Audio, Video und beliebige Daten zu öffnen, ohne Plugins oder zusätzliche Software. Es ist dieselbe Technikfamilie, die hinter den meisten Anrufen im Browser steckt.
WebRTC erledigt die zwei schwersten Teile leise für uns: durch Firewalls zu kommen und die Leitung Ende zu Ende zu verschlüsseln.
WebRTC (Web Real-Time Communication) ist ein offener Standard, der dem Browser Peer-Verbindungen, Medienspuren und Datenkanäle zugänglich macht. Er bündelt die Verbindungslogik, die Sicherheitsschicht und die Medienverarbeitung hinter einer Schnittstelle, sodass eine Anwendung einen verschlüsselten, NAT-überwindenden Transport erhält, ohne diese Schichten selbst zu bauen.
ICE und STUN: einen Weg hindurch finden
Um wirklich zu verbinden, sammelt jedes Gerät eine Liste möglicher Erreichbarkeiten: seine Adresse im lokalen Netz und seine öffentliche Adresse, wie sie aus dem weiten Internet erscheint. Diese öffentliche Adresse zu erfahren heißt, einen einfachen Helfer im offenen Internet zu fragen: „Von welcher Adresse siehst du meinen Verkehr kommen?“ Dieser Helfer ist ein STUN-Server.
Das gesamte Verfahren, diese Kandidatenwege zu sammeln und dann zu testen, welcher tatsächlich funktioniert, heißt ICE.
ICE (Interactive Connectivity Establishment) sammelt Kandidaten: lokale Schnittstellenadressen, die über STUN (Session Traversal Utilities for NAT) entdeckte öffentliche Abbildung und weitergeleitete Adressen (siehe TURN unten). Die Kandidaten werden ausgetauscht und in Prioritätsreihenfolge mit Verbindungstests geprüft, bis ein funktionierendes Paar gefunden ist — oft, indem ein Loch durch beide Router „gestoßen“ wird, indem ausgehende Pakete jede Seite darauf vorbereiten, den passenden Rückverkehr zu akzeptieren.
TURN: ein Relais für die unmöglichen Fälle — und ein Schutzschild für die Privatsphäre
Manchmal sind zwei Netze so streng abgeriegelt, dass überhaupt kein direkter Weg existiert. Für diese Fälle gibt es einen Relais-Server, der ein Protokoll namens TURN nutzt und Verkehr schlicht zwischen den beiden Geräten weiterleitet.
Zwei Dinge sind hier wichtig. Erstens bearbeitet das Relais nur bereits verschlüsselte Daten — es kann Ihre Nachrichten nicht lesen. Zweitens spricht jede Seite mit dem Relais statt direkt mit der anderen, sodass kein Gerät je die echte IP-Adresse des anderen erfährt. So wird die Notlösung zugleich zu einer Möglichkeit, Ihren Standort zu verbergen — und kann genau dafür bewusst gewählt werden.
TURN (Traversal Using Relays around NAT) vergibt eine Relais-Adresse, an die beide Peers senden; der Server leitet die Pakete zwischen ihnen weiter. Er transportiert nur den bereits verschlüsselten Strom, der Betreiber kann den Inhalt also nicht sehen. Die Weiterleitung über das Relais verbirgt zudem die Adresse jeder Seite vor der anderen — weshalb es bewusst für IP-Privatsphäre bevorzugt werden kann, nicht nur als Notlösung. Die Zugangsdaten für das Relais sind kurzlebig und werden pro Sitzung ausgestellt.
Den Kanal verriegeln: Ende-zu-Ende-Verschlüsselung
Sobald ein Weg gefunden ist, einigen sich die beiden Geräte direkt miteinander auf Schlüssel und hüllen die gesamte Verbindung in starke Verschlüsselung, bevor echte Daten fließen. Audio und Video schützt die in WebRTC eingebaute Schicht für sichere Medien; Text und Dateien werden zusätzlich mit dem Schlüssel aus Ihrem Link versiegelt.
Zu keinem Zeitpunkt existiert lesbarer Inhalt irgendwo außer auf den beiden beteiligten Geräten.
Der Transport wird gesichert, indem mit DTLS Schlüssel etabliert und Medien mit SRTP geschützt werden; in den Sitzungsbeschreibungen mitgeführte Zertifikat-Fingerprints werden geprüft, um Manipulation zu erkennen. Darüber hinaus werden Nachrichten und Dateien der Anwendung unabhängig mit einem aus dem Link-Fragment abgeleiteten AES-GCM-Schlüssel versiegelt — das ergibt Vertraulichkeit und Integrität, die Ende-zu-Ende und unabhängig von der darunterliegenden Transportverschlüsselung sind.
Was unsere Server sehen können — und was nicht
Zählt man alles zusammen, ist das Bild einfach. Wir helfen zwei Geräten, einander zu finden, und leiten in seltenen Fällen verschlüsselte Pakete zwischen ihnen weiter. Wir halten nie Ihre Schlüssel, sehen nie Ihre Nachrichten, Dateien oder Anrufe und schreiben keinen Gesprächsverlauf in einen Speicher.
Endet eine Sitzung, sind die wenigen Handshake-Daten, mit denen Sie verbunden wurden, verschwunden.
Der gesamte serverseitige Fußabdruck besteht aus: einem kurzen Austausch von Sitzungsbeschreibungen und Verbindungskandidaten im Arbeitsspeicher; optionalem Weiterleiten undurchsichtiger verschlüsselter Pakete; und dem Ausstellen kurzlebiger Relais-Zugangsdaten. Es werden keine Inhalte, keine Entschlüsselungsschlüssel und keine Nachrichten- oder Teilnehmerprotokolle aufbewahrt. Das ist eine Eigenschaft der Bauweise, kein Schalter, den man umlegen könnte.
Dauerhafte Meetings: derselbe Link, immer wieder
Ein Meeting ist einfach ein Link, den Sie wiederverwenden können. Der Link bleibt gleich, Sie können ihn also einmal senden und sich später erneut treffen. Öffnet ein Gast ihn, sieht er einen kurzen Wartebildschirm; in dem Moment, in dem Sie — der Gastgeber — das Meeting von Ihrem Gerät öffnen, sind Sie beide verbunden und das Gespräch beginnt.
Dieser Wartebildschirm stellt nur eine einzige Frage — „Ist der Gastgeber schon da?“ — und transportiert nie irgendeinen Inhalt.
Für wiederverwendbare Meetings zeigt ein leichtgewichtiges Präsenzsignal an, wann das Gerät des Gastgebers aktiv ist. Ein Gast, der den Link öffnet, prüft eine minimale Statusauskunft, die nur zurückgibt, ob das Meeting existiert und ob der Gastgeber anwesend ist — kein Inhalt, kein Schlüssel. Sobald der Gastgeber online ist, wird der Gast in den verschlüsselten Kanal weitergeleitet, wo derselbe Ablauf aus Signaling und direkter Verbindung übernimmt.
Die Begriffe, an einem Ort
Peer-to-Peer (P2P)
Eine Verbindung, die direkt zwischen zwei Geräten läuft, statt über einen zentralen Server, der alles speichert oder weiterleitet.
WebRTC
Der Browser-Standard, der zwei Browsern erlaubt, eine direkte, verschlüsselte Leitung für Audio, Video und Daten zu öffnen — ohne Plugins.
NAT
Network Address Translation — die Router-Funktion, die viele Geräte sich eine öffentliche Internetadresse teilen lässt und direkte Verbindungen erschwert.
Signaling
Der einleitende Austausch, der zwei Geräte einander vorstellt. Er transportiert nur Verbindungsdetails, nie Gesprächsinhalte.
ICE
Interactive Connectivity Establishment — das Verfahren, mögliche Netzwege zu sammeln und zu testen, bis einer funktioniert.
STUN
Ein Helfer-Server, der einem Gerät verrät, wie seine öffentliche Internetadresse von außen aussieht.
TURN
Ein Relais, das verschlüsselten Verkehr weiterleitet, wenn ein direkter Weg unmöglich ist — und das zugleich die Adresse jedes Geräts vor dem anderen verbirgt.
Sitzungsbeschreibung (SDP)
Die kurze Notiz, die beschreibt, was ein Gerät unterstützt und wie es erreichbar ist, ausgetauscht beim Signaling.
DTLS / SRTP
Die Standard-Schichten, die innerhalb von WebRTC die Schlüssel für die laufende Verbindung etablieren und Audio und Video verschlüsseln.
AES-GCM
Ein weit verbreitetes Verschlüsselungsverfahren; hier schützt es Ihre Texte und Dateien mit dem Schlüssel aus Ihrem Link.
Ende-zu-Ende-Verschlüsselung (E2EE)
Verschlüsselung, bei der nur die beiden Endpunkte den Inhalt lesen können — kein Server dazwischen kann es je.
URL-Fragment
Der Teil eines Links hinter dem „#“, den Browser lokal behalten und nie an einen Server senden.
Das ist der ganze Weg
Meeting erstellen, Link teilen — der Rest passiert direkt zwischen Ihren Geräten.