Sicherheit von WebRTC-Daten

Eines der wichtigsten Argumente für den Einsatz von WebRTC ist die Sicherheit der übertragenen Daten. Deshalb wird hier ein kurzer Überblick über die verschiedenen Datentypen, Übertragungspfade und Verschlüsselungsverfahren gegeben, welche die Sicherheit von WebRTC ausmachen. Der Beitrag beleuchtet die Thematik aus dem Anwenderblickwinkel ohne technisch in die Tiefe z. B. in Bezug auf Kryptologie-Techniken zu gehen.

Zunächst zeigt die folgende Grafik die typische Infrastruktur eines WebRTC-Systems mit den beteiligten Server-Komponenten und Datenpfaden.

WebRTC_Security Die Datenpfade einer WebRTC-Anwendung wie melavi sind:
  1. die Verbindung zwischen Web-Client (Browser, Peer) und dem Web-Server, welcher die Web-Anwendung hostet. Dieser Datenkanal überträgt HTML-Dokumente, Ajax-Daten, Scripte wie Javascript und CSS und die üblichen Ressourcen einer Web-Anwendung wie z. B. Bilder oder Audio-Daten.

  2. der Signalisierungs-Kanal. Über diesen Kanal übertragen die Teilnehmer einer WebRTC-Session Daten, die für den Aufbau der eigentlichen Nutzdatenverbindung benötigt werden. Dies sind die öffentlichen Internet Adressen und Ports über die die Teilnehmer miteinander kommunizieren können und Meta-Daten, welche die eigentlichen Nutzdaten der WebRTC-Verbingung beschreiben. Dazu gehören z. B. Informationen zum verwendeten Video- oder Audio-Kompressions-Verfahren und zu dessen Parametern.

    Es ist möglich, dass die Daten des Signalisierungs-Kanals über den Datenkanal 1 übertragen werden. Da der WebRTC-Standard aber hier keine Festlegungen trifft, sind verschiedenste Techniken im Einsatz. Meist wird ein separater Signalisierungs-Server eingesetzt und damit die WebRTC-Signalisierungs-Daten über einen eigenen Kanal zwischen den Peers übertragen.

  3. der Haupt-Nutzdaten (Payload) Kanal von WebRTC. Über diesen Kanal werden Audio-, Video- und sonstige Nutzdaten von WebRTC übertragen. WebRTC-Nutzdaten werden in ca 85% der Fälle direkt zwischen den beteiligten Teilnehmern (Peers) übertragen. Die restlichen 15% werden über einen Relay- bzw TURN-Server (Traversal Using Relays around NAT) übertragen, wenn die Eigenschaften des Teilnehmer-Anschlusses (NAT - Network Address Translation - oder Firewall) eine direkte Verbindung nicht erlauben.

  4. der Relay-Nutzdaten Kanal von WebRTC. Dieser Kanal überträgt die WebRTC-Nutzdaten, wenn eine direkte Peer to Peer Verbindung der Teilnehmer wegen der Eigenschaften der Netzanschlüsse nicht möglich ist.

  5. der STUN (Session Traversal Utilities for NAT) Datenkanal. STUN ist eine Infrastruktur-Komponente von WebRTC (und VoIP). Es findet eine Kommunikation zwischen den Peers einer WebRTC-Session und einem STUN-Server statt. Ziel ist die Ermittlung der öffentlich sichtbaren IP-Adressen und Ports der Peers, die sich normalerweise in Intranets hinter NAT-Routern befinden. Die übertragenen Daten sind aus Sicht der Datensicherheit unproblematisch. Es werden keine Nutz- oder Verbindungs-Daten über diese Strecke übertragen.

Die Datenpfade einer WebRTC-Anwendung werden folgendermaßen abgesichert:

  1. Der Web-Anwendungs-Datenpfad wird über die üblichen Verfahren zur Absicherung von Web-Anwendungen gesichert. Dazu werden verschlüsselte und zertifizierte ssl (bzw. TLS) Verbindungen verwendet.

  2. Der WebRTC-Standard fordert nicht explizit die Absicherung der Signalisierungs-Daten. Im Vergleich zu den Nutzdaten sind diese Daten relativ unkritsch, da keine Inhalte sondern lediglich Verbindungs-Status-Informationen übertragen werden. Nichtsdestotrotz sollte eine Anwendung mit WebRTC-Komponenten auch diesen Datenpfad gegen Protokollierungs- und Manipulations-Angriffe absichern. Wird die Signalisierung über den Web-Server vorgenommen, so sind die Daten sicher, wenn die Web-Anwendung ssl-Verbindungen nutzt. Wird ein separater Signalisierungs-Server und z. B. die WebSocket-Technologie für die Übertragung eingesetzt, so sollte hier ebenfalls eine ssl-Absicherung mit Authentifizierung über entsprechende Zertifikate erfolgen.

  3. WebRTC-Nutzdaten werden prinzipiell immer verschlüsselt übertragen. Dies ist eine Kern-Forderung des WebRTC-Standards. Der Datenaustausch erfolgt über das SRTP Verfahren. Bei jeder neuen WebRTC-Nutzdatenverbindung werden individuelle Schlüssel zwischen den Peers ausgehandelt. Diese Schlüssel für den Zugriff auf die SRTP-verschlüsselten Nutzdaten kennen nur die beiden Peers. Für den Austausch und die Aushandlung der Schlüssel wird bei SRTP das DTLS-SRTP Verfahren eingesetzt. Dies ist eine Anpassung des aus dem Web-Bereich bekannten TLS (ssl) für das bei WebRTC verwendete Daten-Transport-Protokoll UDP. Das Verfahren garantiert eine Übertragung der Schlüssel, die sicherstellt, dass nur die beiden Peers einer WebRTC-Übertragung Kenntnis dieser Schlüssel haben. Damit sind "man in the middle" Angriffe auf die Nutzdaten ausgeschlossen. Es besteht weder eine Möglichkeit der Manipulation der Inhalte noch eine Einsicht in die Daten auf der Übertragungsstrecke.

  4. Der alternative Relay-Nutzdatenkanal ist auf die gleiche Weise wie der Haupt-Nutzdatenkanal abgesichert. Der TURN-Relay Server hat keine Kenntnis der Schlüssel für den Zugriff auf die von ihm an die Peers weitergeleiteten Nutzdaten. Der Server leitet lediglich die verschlüsselten SRTP-Nutzdatenpakete weiter ohne auf den Paket-Inhalt zugreifen zu müssen. Damit ist die Relay-Verbindung genauso sicher, wie die direkte Peer to Peer Verbindung. TURN-Server stehen im Internet als frei nutzbare Ressource zur Verfügung. Nichtsdestotrotz empfiehlt sich der Einsatz selbst-gehosteter TURN-Server bzw. vertrauenswürdiger Provider für eine kritische WebRTC-Anwendung. Damit ist auch die Server-seitige Protokollierung von (verschlüsselten) Paketen und Verbindungs-Statistiken ausgeschlossen - bzw. in der Hoheit des Betreibers des WebRTC-Systems.

  5. Die STUN-Daten von WebRTC sind nicht Sicherheits-relevant. Eine besondere Absicherung der Kommunikation zwischen den Peers und einem STUN-Server muss nicht vorgenommen werden. Wie beim TURN-Server empfiehlt sich aber der Einsatz vertrauenswürdiger Infrastruktur-Server.

Damit gelten die folgenden allgemeinen Aussagen zur Sicherheit von WebRTC-Daten:

  • Die Sicherheit der WebRTC Nutzdatenübertragung ist durch die Verwendung von standardisierten Verschlüsselungsverfahren wie SRTP und DTLS garantiert.

  • Der WebRTC Standard fordert, dass sämtliche Nutzdaten verschlüsselt übertragen werden müssen. Unverschlüsselte Nutzdaten werden nicht akzeptiert und werden von den WebRTC Endpunkten (Browser) nicht unterstützt.

  • WebRTC hat keine proprietären Komponenten und damit keine Hersteller-abhängigen „Hintertüren“ für den Zugriff auf die Nutzdaten.

  • Die der WebRTC Nutzdatenübertragung zugrunde liegenden Verschlüsselungsstandards sind in anderen Umgebungen (ssl/https...) in Nutzung und unterliegen ständiger öffentlicher Kontrolle, so dass Lücken in den Standards oder Probleme durch technischen Fortschritt schnell bereinigt werde.

  • Durch den Plattform-übergreifenden Standard (Browser und Betriebssysteme) sind die Browser-Hersteller zur Kompatibilität auch in Bezug auf die Verschlüsselungs-Standards gezwungen. Hersteller-abhängige Hintertüren sind damit auszuschließen.

  • Die Nutzdatenübertragung erfolgt im Allgemeinen Peer to Peer. Nur die Peers kennen die für eine Session ausgehandelten Schlüssel. Auch eine indirekte (Relay) Übertragung ist durch die Endpunkt zu Endpunkt Verschlüsselung sicher, da der Relay Server keinen Zugriff auf die unverschlüsselten Daten hat.

  • Die sonstigen Daten einer WebRTC Session können konventionell über ssl-Verbindungen abgesichert und mit entsprechenden vertrauenswürdigen Zertifikaten beglaubigt werden.

  • Zumindest in Bezug auf die Sicherheit der Nutzdaten muss der Betreiber einer WebRTC-Anwendung keine besonderen Maßnahmen zur Absicherung vornehmen. Der WebRTC-Standard garantiert die Sicherheit. In Bezug auf die anderen Datenkanäle der Anwendung müssen die üblichen Sicherungs-Werkzeuge von Web-Anwendungen installiert werden.

Auf den Punkt gebracht, kann man die Aussage formulieren - WebRTC-Datenkanäle sind so sicher wie es der heutige Stand öffentlicher standardisierter Internet-Verschlüsselungs-Technologien zulässt.