Die meisten Videokonferenzen vertrauen einem zentralen Server: Er nimmt Bild und Ton aller Teilnehmenden entgegen, verteilt sie weiter und entscheidet, wer hereinkommt. Briefing dreht das um. Der Leitgedanke lautet:
Der Server vermittelt, aber man muss ihm nicht vertrauen. Ein kompromittierter oder ausgefallener Server kann ein Gespräch stören - aber er kann es nie mitlesen, nie betreten, sich nie als jemand anderes ausgeben und es nicht beenden.
Diese Seite erklärt, wie das technisch funktioniert. Eine Anleitung zur Bedienung findest du in der Hilfe.
Kurz gesagt
| Üblicher Videodienst | Briefing | |
|---|---|---|
| Weg von Bild und Ton | über einen zentralen Medienserver (SFU) | direkt von Browser zu Browser |
| Verschlüsselung | meist nur bis zum Server, Ende-zu-Ende oft optional | immer Ende-zu-Ende |
| Wer kennt den Schlüssel? | häufig der Anbieter | nur wer den Link hat |
| Wer entscheidet über den Einlass? | der Server | die Teilnehmenden im Raum |
| Kennt der Server den Raumnamen? | ja | nein |
| Gespräch bei Serverausfall | bricht ab | läuft weiter |
| Konto, App, Tracking | meist nötig bzw. vorhanden | nichts davon |
| Aufzeichnung auf dem Server | oft möglich | nichts wird gespeichert |
Direkt statt über einen Medienserver
Große Videodienste schicken Bild und Ton aller Teilnehmenden an einen zentralen Medienserver (eine Selective Forwarding Unit, kurz SFU), der die Datenströme an alle anderen verteilt. Das skaliert gut für große Runden, hat aber einen Preis: Die Transportverschlüsselung endet am Server. Er hat Zugriff auf alle Medien - ob er sie nutzt, ist eine Frage des Vertrauens in den Anbieter.
Briefing verbindet die Teilnehmenden direkt miteinander (ein sogenanntes Mesh) über WebRTC, den Standard für Echtzeit-Kommunikation, den jeder moderne Browser eingebaut hat. Bild und Ton sind zwischen den Browsern mit DTLS-SRTP verschlüsselt, Chat, Dateien und Dokumente zusätzlich mit dem Raumschlüssel. Es gibt keinen Punkt, an dem alles zusammenläuft.
Ehrlicherweise: Im Mesh schickt jeder sein Bild an jeden anderen. Mit jeder weiteren Person wächst also der Upload. Briefing ist deshalb für kleine Gruppen gedacht und hält den Aufwand klein, indem jeder nur so viel Videoqualität sendet, wie beim Empfänger gerade angezeigt wird - eine Miniatur bekommt ein kleines Bild, ein verborgener Tab fast nichts.
Wenn eine Verbindung nicht direkt klappt
Strenge Firewalls verhindern manchmal eine direkte Verbindung. Dann springt ein Relay-Server (TURN) ein. Er reicht nur die bereits verschlüsselten Pakete weiter und kann nichts davon lesen - anders als ein Medienserver.
Der Schlüssel steckt im Link
Ein Briefing-Raum ist ein Link aus zwei Teilen: dem Raumnamen und - hinter dem # - dem Passwort. Den Teil hinter dem # überträgt ein Browser grundsätzlich nicht an den Server. Briefing nutzt das:
- Aus Passwort leitet der Browser den Raumschlüssel ab (PBKDF2 mit 600.000 Runden, dann AES-GCM). Mit ihm wird alles verschlüsselt, was über den Server läuft oder zwischen den Teilnehmenden ausgetauscht wird. Jede Nachricht ist dabei an ihren Zweck und ihre Richtung gebunden, sodass ein mitgeschnittenes Paket an anderer Stelle nicht wieder eingespielt werden kann.
- Aus Name und Passwort berechnet der Browser eine Raum-ID. Nur sie bekommt der Server zu sehen. Sie lässt sich nicht zurückrechnen, und ohne Passwort kann niemand einen Raum finden, belegen oder auch nur prüfen, ob er existiert.
Unter demselben Namen kann es deshalb beliebig viele getrennte Räume geben. Wer ein falsches Passwort eingibt, landet nicht vor einer verschlossenen Tür, sondern in einem leeren Raum.
Die Teilnehmenden entscheiden, wer hereinkommt
Damit sich zwei Browser direkt verbinden können, müssen sie erst Verbindungsdaten austauschen - das sogenannte Signaling. Dafür braucht es einen Server, über den man sich findet. Bei Briefing sieht er dabei nur Geheimtext:
- Ben betritt den Raum und schickt die Raum-ID und eine mit dem Raumschlüssel verschlüsselte Beitrittsnachricht.
- Der Server kann sie nicht lesen. Er reicht sie unverändert an Anna weiter, die schon im Raum ist.
- Anna entschlüsselt die Nachricht und prüft, ob sie zu diesem Raum gehört, ob sie frisch ist und ob sie genau die Teilnehmer-ID nennt, unter der Ben auftritt. Niemand kann so die Identität eines anderen übernehmen.
- Erst wenn das passt, wird Ben aufgenommen.
- Anna und Ben tauschen ihre Verbindungsangebote (SDP, ICE) über den Server aus - verschlüsselt und an die Richtung gebunden.
- Die Direktverbindung steht.
Lässt ein manipulierter Server trotzdem jemanden herein, gewinnt er nichts: Ohne Raumschlüssel gibt es nichts zu entschlüsseln und keine Verbindung aufzubauen.
Das Gespräch braucht den Server nicht
Sobald die Verbindung steht, läuft auch das weitere Signaling (etwa wenn jemand den Bildschirm teilt) direkt zwischen den Browsern. Der Server erfährt davon nichts mehr. Ein Neustart, ein Update oder ein Ausfall des Servers unterbricht ein laufendes Gespräch deshalb nicht. Ist der Server wieder da, melden sich alle unauffällig zurück. Gebraucht wird er nur zum Betreten eines Raums.
Sicherheitscodes: Sitzt jemand dazwischen?
Was wäre, wenn sich jemand mit Zugriff auf den Server und dem Raum-Link zwischen zwei Teilnehmende schaltet? Dagegen helfen die Sicherheitscodes: Für jede Direktverbindung zeigt Briefing sechs Symbole, berechnet aus den Zertifikaten, die die beiden Browser tatsächlich verwenden.
- Sind beide direkt verbunden, sehen beide dieselben Symbole.
- Sitzt jemand dazwischen, hat jede Seite in Wirklichkeit eine Verbindung zum Angreifer - und die Symbole unterscheiden sich.
Ihr findet sie unter Einstellungen → Sicherheitscodes. Lest sie euch zu Beginn eines vertraulichen Gesprächs einfach vor.
Ganz ohne Server
Konsequent zu Ende gedacht, braucht Briefing nicht einmal zum Finden einen Server. Im experimentellen Modus Ohne Server verbinden tauscht ihr Einladung und Antwort selbst aus, per QR-Code oder Messenger:
- Anna erstellt eine Einladung. Sie enthält das Raum-Passwort und Annas Netzwerkadressen.
- Ben öffnet sie und schickt eine Antwort zurück, verschlüsselt mit dem Raumschlüssel.
- Anna und Ben sind direkt verbunden. Lädt Ben nun Carla ein, stellt er sie über die bestehenden Verbindungen auch Anna vor, sodass alle miteinander verbunden sind.
Kein Signaling-Server ist beteiligt. Weil die Einladung Passwort und Netzwerkadressen enthält, gehört sie nur in die Hände der eingeladenen Person. Ob unterwegs jemand die Einladung verändert hat, zeigen die Sicherheitscodes.
Was der Server weiß - und was nicht
| Der Signaling-Server sieht | Der Signaling-Server sieht nicht |
|---|---|
| die Raum-ID (nicht umkehrbar) | den Raumnamen |
| zufällige Teilnehmer-IDs, gewählt vom Browser | Namen oder Profilbilder |
| verschlüsselte Nachrichten zum Verbindungsaufbau | deren Inhalt |
| Verbindungszeitpunkte und IP-Adressen (ohne sie geht es im Netz nicht) | Bild, Ton, Chat, Dateien, Dokumente |
| das Passwort oder den Raumschlüssel |
Die Nutzungsstatistik speichert Räume nur als gesalzene Hashwerte und Teilnehmende gar nicht. Push-Benachrichtigungen enthalten nur die Raum-ID. Alle Logs werden rotiert. Details stehen in der Datenschutzerklärung.
Prüfbar statt versprochen
- Verschlüsselung im Browser: Ver- und Entschlüsselung erledigen die eingebauten Kryptofunktionen deines Browsers (Web Crypto). Mit den Entwicklerwerkzeugen des Browsers lässt sich beobachten, dass zum Server nur Geheimtext geht.
- Strenge Sicherheitsrichtlinie (CSP): Der Browser führt nur Code aus, den die Instanz selbst ausliefert - kein nachgeladenes Skript von fremden Servern, keine Web-Fonts, kein CDN.
- Code-Fingerabdruck: Die Startseite zeigt einen Fingerabdruck über die App-Dateien, die dein Browser tatsächlich verwendet. Er lässt sich mit dem veröffentlichten Fingerabdruck des Releases vergleichen.
- Updates nur auf Klick: Eine neue Version übernimmt nie unbemerkt einen laufenden Tab.
- Selbst betreiben: Briefing läuft als einzelnes Docker-Image, jede Funktion auch ohne unsere Infrastruktur. Die offizielle Instanz läuft ausschließlich in Rechenzentren in Deutschland.
Die Grenzen
Kein System ist ohne Kompromisse. Diese solltest du kennen:
- Der Link ist der Schlüssel. Wer ihn hat, kommt herein. Verschicke ihn nur über Wege, denen du vertraust, und setze im Zweifel ein neues Passwort.
- Direkte Verbindungen zeigen IP-Adressen. Damit sich Browser direkt erreichen, erfahren die Teilnehmenden gegenseitig ihre Netzwerkadressen.
- Kleine Gruppen. Ohne Medienserver wächst der Upload mit jeder Person. Für große Konferenzen ist ein anderes Werkzeug besser geeignet - welches, zeigt Briefing im Vergleich.
- Metadaten. Auch Briefings Server sieht, wann sich welche IP-Adresse mit einer Raum-ID verbindet - nur nicht, worum es geht.
- Medienserver als Option. Betreiber können statt des Mesh einen LiveKit-Medienserver einsetzen. Einlass, Chat und Daten bleiben dann Ende-zu-Ende verschlüsselt, Bild und Ton laufen aber über diesen Server, und die Sicherheitscodes stehen nicht zur Verfügung.