Ist WebRTC sicher? Wie Peer-to-Peer-Präsentationen Ihre Inhalte schützen

„Ist WebRTC sicher?“ gehört zu den Fragen, die einfach klingen und eine fundierte Antwort verdienen, vor allem wenn Sie gleich eine Vorstandspräsentation, ein Investorengespräch oder einen Kundenpitch darüber abwickeln. Die Kurzfassung lautet: ja, und zwar konstruktionsbedingt. Die ehrliche Fassung erklärt aber auch, warum, denn „das ist ein Webstandard“ ist für sich genommen noch kein Argument.

WebRTC ist die Technologie hinter den meisten modernen Peer-to-Peer-Video- und Steuerungstools, darunter die Verbindung zwischen dem Smartphone der Vortragenden und dem Computer, auf dem die Folien in Cliqer laufen. Wer versteht, was diese Technologie schützt und was nicht, kann jedes Tool, das sie nutzt, besser beurteilen, nicht nur unseres.

Was WebRTC eigentlich ist

WebRTC (Web Real-Time Communication) ist ein offener Standard, der vom W3C gepflegt und von allen großen Browsern nativ unterstützt wird. Er legt fest, wie zwei Geräte eine direkte Verbindung aufbauen, um Audio, Video oder beliebige Daten auszutauschen, ohne dass eine Seite ein Plugin installieren muss. Die technische Spezifikation und Hintergründe finden Sie unter webrtc.org.

Das entscheidende Wort ist „direkt“. Anders als bei einem Videocall, der komplett über die Server eines Unternehmens läuft, ist WebRTC darauf ausgelegt, zwei Geräte so direkt miteinander zu verbinden, wie es das Netzwerk zulässt, und nur dann auf ein Relay auszuweichen, wenn kein direkter Pfad möglich ist. Genau diese eine Designentscheidung macht den Rest dieses Artikels relevant: Ein Protokoll, das auf direkten Verbindungen aufbaut, braucht ein anderes Sicherheitsmodell als eines, das auf einem zentralen Server aufbaut, und es lohnt sich, beide Seiten zu verstehen, bevor Sie ihm die Inhalte aus dem Sitzungssaal anvertrauen.

Verschlüsselung ist bei WebRTC nicht optional

Dieser Teil beantwortet die Sicherheitsfrage tatsächlich. WebRTC bietet keinen unverschlüsselten Modus. Jede WebRTC-Verbindung, ob sie einen Datenkanal, Audio oder Video überträgt, ist konstruktionsbedingt verschlüsselt:

• DTLS (Datagram Transport Layer Security) sichert Datenkanäle, also die latenzarme Leitung für Dinge wie Befehle zum Folienwechsel und Pointer-Positionen.
• SRTP (Secure Real-time Transport Protocol) sichert alle Audio- und Videomedien, etwa eine Bildschirmfreigabe oder ein Kamerabild.
• Der erste Handshake, der eine Verbindung aufbaut (das sogenannte Signaling), läuft separat über WSS (WebSocket Secure), sodass auch der Koordinationsschritt verschlüsselt ist, noch bevor die Peer-to-Peer-Verbindung besteht.

Es gibt keine Einstellung, mit der sich das abschalten lässt. Es ist fest im Standard verankert, und das ist eine deutlich andere Garantie als „wir haben uns entschieden, Verschlüsselung zu aktivieren“, weil sie sich nicht unbemerkt falsch konfigurieren lässt.

Peer-to-Peer oder über Server: warum das für Inhalte wichtig ist

Weil WebRTC Geräte direkt verbindet, hat eine darauf aufbauende Anwendung eine echte Wahl, die serverbasierte Tools nicht haben: ob Inhalte überhaupt jemals einen Server berühren müssen. In Cliqer laufen Befehle zum Folienwechsel, Laserpointer-Koordinaten, Timer-Status sowie jeder Bildschirm- oder Kamerastream direkt zwischen dem Gerät der Vortragenden und dem Host-Computer oder über ein verschlüsseltes Relay, falls kein direkter Pfad verfügbar ist. Die Anwendungsserver koordinieren, wer sich im Raum befindet; sie sind nie Teil des Medienpfads selbst, und Ihre Präsentationsinhalte werden nie hochgeladen.

Diese Architektur ist vor allem bei sensiblen Inhalten entscheidend: Vorstandsfolien, Produkt-Roadmaps, unveröffentlichte Finanzzahlen. Mehr zu genau diesem Fall lesen Sie unter vertrauliche Inhalte präsentieren.

Wo das Relay ins Spiel kommt

Nicht jedes Netzwerk erlaubt eine direkte Verbindung. Firmen-Firewalls, Hotel-WLAN und Carrier-Grade NAT können den direkten Pfad blockieren, den WebRTC bevorzugt. In diesem Fall weicht die Verbindung auf ein TURN-Relay aus, das dieselben per DTLS und SRTP verschlüsselten Pakete weiterleitet, ohne die Schlüssel zu besitzen, um sie zu entschlüsseln. Das Relay transportiert Bytes; lesen kann es sie nicht.

Wie dieser Fallback genau funktioniert und warum er keine Abstriche bei der Sicherheit bedeutet, erklären wir in TURN-Server erklärt. Das ist auch der Grund, warum Firmen-Firewalls ein gut gebautes WebRTC-Tool selten komplett blockieren, ein Thema, das wir in Warum Firmen-Firewalls Präsentationstools blockieren behandeln.

Wovor WebRTC nicht schützt

Verschlüsselung bei der Übertragung ist nicht die ganze Sicherheitsgeschichte, und es lohnt sich, ehrlich zu sagen, was sie nicht abdeckt:

So prüfen Sie es selbst

Sie müssen sich bei alldem nicht auf das Wort eines Anbieters verlassen. Ein paar praktische Prüfungen:

1. Fordern Sie ein Datenflussdiagramm an, keine Marketingseite, und klären Sie, welche Datenflüsse Peer-to-Peer laufen und welche über Server.
2. Prüfen Sie, ob die App eingehende Firewall-Regeln benötigt. Eine sauber gebaute WebRTC-App sollte nur ausgehende Verbindungen brauchen.
3. Fragen Sie, was in einem Netzwerk passiert, das direkte Verbindungen blockiert. Es sollte einen verschlüsselten Relay-Fallback geben, keinen harten Abbruch.
4. Lesen Sie die Dokumentation zu Sicherheit & Netzwerk für die konkret verwendeten Ports und Protokolle.

Wenn Sie ein Tool für ein ganzes Team prüfen statt für einen einzelnen Call, nehmen Sie diese Punkte in die umfassendere Sicherheits-Checkliste für Präsentationssoftware auf, denn Verschlüsselung ist nur einer von mehreren Punkten, die eine gründliche Prüfung abdecken sollte.

FAQ

Jetzt loslegen

Wenn Verschlüsselung und Peer-to-Peer-Routing für Ihre Bewertung von Präsentationstools wichtig sind, lesen Sie die vollständige Sicherheitsübersicht oder testen Sie Cliqer kostenlos und prüfen Sie das Verbindungsverhalten selbst, bevor Sie damit sensible Inhalte präsentieren.