WebRTC

October 9, 2021 Papers

PDF File

1. Einleitung

1.1 Hintergrund

Web Real-Time Communication abgekürzt WebRTC ist eine 2011 von Google veröffentlichte Open Source Technologie, die eine Vielzahl von APIs und Protokollen zur Echtzeit Kommunikation über den Browser definiert. Initiales Ziel war eine Standardisierung und Innovation des Webbrowser Kommunikationsmodell, die es erlaubt eine Peer-zu-Peer Verbindung, ohne externe Software aufzubauen um Videostreams, Nachrichten und Daten auszutauschen [1]. Der Standard wird heute von IETF [2] and W3C [3] durch JavaScript APIs und HTML Tags festgelegt und ist laut [4] Grundlage von Produkten wie Google Hangouts, Facebook Message und Discord.

1.2 Client-Server-Modell

Klassische Web Architekturen wie in [5, S. 7-10], basieren auf dem Client-Server-Modell, welches die Beziehung in der zwei Programme zueinander stehen beschreibt, wobei der Client als Auftraggeber und der Server als Auftragsnehmer agiert. Hierbei sendet der Client, in diesem Fall der Browser, eine HTTP/HTTPS Anfrage an den Webserver, welcher im Gegenzug mit der angefragten Website antwortet. Ressourcen werden durch URI oder URL eindeutig gekennzeichnet und durch Repräsentationsformate wir HTML, CSS und XML vereinheitlicht. Nutzerinteraktion kann durch JavaScript oder PHP-Code erzeugt werden, welcher durch APIs mit dem Server beziehungsweise durch das User Interface mit dem Benutzer kommuniziert. Als Kommunikationsbasis dient hierbei eine ganze Internetprotokollfamilie die größtenteils auf dem TCP/IP-Referenzmodell basiert.

Abbildung 1: Client/Server-Modell [5, S. 8]

1.3 WebRTC Architektur

WebRTC erweitert das klassische Client-Server-Modell um die Multi-Plattform Peer-to-Peer Kommunikation, die keine zusätzlichen Server oder Plug-Ins zur Kommunikation benötigt. In einem Peer-to-Peer Netzwerk [6] hat jeder Teilnehmer die gleiche Berechtigung, dies bedeutet er ist gleichzeitig Client als auch Server und besitzt eine direkte Verbindung zu all seinen Nachbarn. Da Kommunikation unmittelbar erfolgt wird auf einen zentralen Knoten zur Peer Interaktionen verzichtet, deshalb spricht man von einem dezentralen Netzwerk. WebRTC Clients können über eine Vielzahl an Plattformen wie VoIP Equipment, Apps oder dem Browser [7] über die WebRTC API Verbindungen herstellen, dies eliminiert den Gebrauch von externer Soft- und Hardware. Die beiden am häufigsten eingesetzten Modelle sind das WebRTC Trapez und Dreieck Modell. Im Trapez Modell laufen die Webseiten auf unterschiedlichen Webservern, welche untereinander über Signaling kommunizieren. Die Signaling Nachrichten werden über HTTP oder einem Websocket an den User weitergeleitet, welche dadurch einen Peer-to-Peer Stream aufbauen können.

Abbildung 2: WebRTC Trapez [8, S. 2]

Am häufigsten wird jedoch das Dreieck Modell genutzt, hierbei werden beide Webanwendungen vom gleichen Webserver geladen was dem Entwickler mehr Freiheiten beim verwalten der Benutzer gibt. [8, S. 2-3]

Abbildung 3: WebRTC Dreieck [8, S. 3]

2. WebRTC API

Die WebRTC API [1] [8, S. 5-9] implementiert die Grundlegenden Fähigkeit, die es einem JavaScript Programm erlauben, WebRTC zu nutzen. Grundlegend unterscheidet man drei Teile, den MediaStream, über welche Eingabegeräte angesteuert werden, um daraus Datenstreams zu generieren. Die RTCPeerConnection welche es den Nutzern erlaubt direkt über den Browser eine Verbindung zu anderen Peers aufzubauen und dem RTCDataChannel, welcher den Transport der Daten über eine Peer-to-Peer Verbindung ermöglicht.

2.1 MediaStream

Der MediaStream erlaubt den Zugriff auf lokale Eingabegeräte und stellt die Funktionalität zur Repräsentation und Manipulation das daraus generierbaren Audio-, Video- oder Textdaten bereit. Um einen lokalen MediaStream zu erzeugen wird zunächst Zugriff auf das vom Benutzer gewählte Eingabegeräte angefragt und dieses klassifiziert. Je nach Klassifizierung wird für jedes Eingabegerät ein MediaStreamTrack erzeugt und mit dem kind Attribut gelabelt, dies lautet beispielsweiß „video" oder „audio". Der MediaStreamTrack kann aus einem oder mehreren Channels, der kleinsten Einheit eines MediaStreams, bestehen. Beispiel [9] hierfür ist ein MediaStreamTrack (Audio) der unterschiedliche Channels für die linke und rechte Seite eines Kopfhörers hat, wenn dieser in Stereo betrieben wird. Die generierten Echtzeit MediaStreamTracks werden von der API als abstraktes, mit dem Erzeuger verknüpftes MediaStream Objekt dargestellt und können als Output an ein oder mehrere Ziele weitergeleitet werden.

Abbildung 4: MediaStream

2.2 RTCPeerConnection

Die RTCPeerConnection ermöglicht es Nutzern direkt über den Browser zu Kommunizieren. Nachdem die beiden Kommunikationspartner die WebRTC Instanz aufgerufen haben wird die Verbindung über das Signaling koordiniert. Ist eine Verbindung zwischen den Peers aufgebaut können MediaStream Objekte direkt über den Browser an den entfernten Benutzer gesendet werden. Zur Ermöglichung von Echtzeit-Kommunikation enthält die WebRTC Architektur Audio, Video und Transport Mechanismen. Der Audio Mechanismus verbessert die Qualität durch das Reduzieren von Rauschen und Echos, der Video Mechanismus durch Bildverbesserung und einen Jitter Buffer. Der Transport Mechanismus wird durch SRTP [10] und ICE, welcher im Abschnitt 3.2 ICE genauer behandelt wird, im Netzwerk umgesetzt. SRTP ist die verschlüsselte Version von RTP welches zur kontinuierlichen paketbasierten Übertragung von Inhalten dient. Zur Überwachung der Dienstqualität wird RTCP genutzt das Steuernachrichten zwischen den Peers austauscht.

2.3 RTCDataChannel

Der RTCDataChannel ist ein Transport Service, der es Webbrowsern erlaubt bidirektional Daten in einem Peer-to-Peer-Netzwerk auszutauschen. Der von der IETF empfohlene Standard ist SCTP [11] welches in DTLS, näher beschrieben in Abschnitt 3.3 DTLS, eingehüllt ist um Vertraulichkeit, Quellauthentifizierung und Integritätsschutz während der Übertragungen zu garantieren. SCTP kann nativ mehrere unabhängige Streams gleichzeitig unterstützen, welche jeweils zuverlässig oder unzuverlässig und in-order oder out-of-order sind. Jeder SCTP Stream ist unidirektional, da die DataChannel API jedoch nur bidirektionale Kommunikation unterstützt, besteht jeder DataChannel aus einem Bündel von ein- und ausgehenden SCTP Streams.

3. Grundlegende Technologien

3.1 Signaling

Um WebRTC möglichst kompatibel zu halten können verschiedene Signaling Standards wie SIP, XMPP, XHR oder SIP über einen WebSocket verwendet werden. Einheitlich ist hierbei jedoch der Datenaustausch der Transportinformationen und ICE Kandidaten, genauer beschrieben in 3.2 ICE, über SDP [13]. Das Session Description Protocol dient zur Verwaltung und Erzeugung von Kommunikationssitzungen bei Multimediadatenströmen und wird beispielsweiße bei Voice-over-IP und Video Streaming eingesetzt. SDP ermöglicht eine standardisierte Darstellung von Informationen und wie diese transportiert werden. Das Protokoll selbst soll nicht in seinen Einsatzbereichen eingeschränkt werden weshalb Informationen wie Media Typen, Format, Codecs und weiteres enthalten sind, jedoch keine Medien Encodierung oder Session Beschreibungen. Eine Beispiel SDP Nutzlast wird in Abbildung 5 dargestellt. Alle SDP und Kontrollnachrichten werden von IETF standardisiert als JSEP [14] übertragen. Der entscheidende Vorteil von JSEP ist das es nur Informationen beinhaltet und der Anwendung das Verarbeiten der Daten zu einer Verbindung überlassen wird, wodurch kein einheitliches Signaling vorausgesetzt ist. Im Abschnitt 4. Beispielanwendung wird dieser Vorgang noch einmal Anhand einer Chatanwendung veranschaulicht.

Abbildung 5: SDP Nutzlast [15 S. 135]

3.2 ICE

Aufgrund der Knappheit von IPv4 Adressen, welche immer noch die meist verbreitetste IP-Version ist, wird ICE benötigt, um eine Verbindung zwischen zwei Clients herzustellen, die sich hinter mehreren Schichten von NAT Mechanismen verbergen. NAT [12] ist ein Verfahren das Absender und Ziel-Adressen von IP-Datenpaketen durch andere IP-Adressen ersetzen kann, dies ermöglicht einem privaten Netzwerke das teilen einer gemeinsamen öffentlichen IP-Adresse. ICE vereinfach die Adressierung, indem es eine Liste von ICE Kandidaten für das SDP Protokoll [13] generiert, welche aus IP und Port Paaren besteht, worüber sich die Clients verbinden können. Die Liste der ICE Kandidaten werden über einen STUN Server gesammelt, welcher es einem Client ermöglich seine öffentlich IP-Adresse und Port herauszufinden. Ist kein direkter Verbindungsaufbau die beiden Peers möglich werden Daten über einen TURN Server weitergeleitet, der für die Clients als Relay zum Datenaustausch dient [1]

Abbildung 6: Interactive Connectivity Establishment

3.3 Sicherheit durch DTLS

Unter dem gängigen WebRTC Standard werden alle Streams durch den bereits initial integrierten Industriestandard DTLS [16] verschlüsselt. DTLS bietet vollständige Verschlüsselung mithilfe asymmetrischer Kryptografie sowie Daten und Nachrichtenauthentifizierung. Es orientiert sich hierbei am Verschlüsslungsprotokoll TLS wird jedoch nicht über TCP sondern über unzuverlässige Transportprotokolle wie UDP übertragen.

4. Beispielanwendung

Zur besseren Visualisierung des Ablaufes wird die Kommunikation einer einfachen Chatanwendung über WebRTC und Signaling über Websockets dargestellt. Wenn ein Anwender die Website aufruft sendet er gleichzeitig die Kennzeichnung „initialize", um herauszufinden, ob er, oder der andere an der Kommunikation beteiligte Client die Sitzung initialisiert. Der Initialisierende bekommt vom Server die Flagge „initiator" und frägt daraufhin die Benutzermedien an, welche es ihm erlauben aus seinen Eingabegeräten MediaStreams zu erstellen. Nun muss der Initialisierende warten, bis der zweite Client den gleichen Vorgang abschließt, dieser wird jedoch nicht als Initialisator gekennzeichnet und erhält dadurch als erstes den PeerChannel und dann Benutzermedien. Nun können beide Seiten die Peer-to-Peer Verbindung aufbauen. Der Initialisierende sendet eine SDP Anfrage und seine ICE Kandidaten an den Server, welcher diese an den zweiten Peer weiterleitet. Peer 2 antwortet im Gegenzug mit seiner SDP Antwort und seinen ICE Kandidaten. Mit diesen Informationen kann eine Verbindung aufgebaut werden, welche den Austausch von Echtzeitnachrichten ohne Nutzung des Servers zwischen den Peers ermöglicht. [1]

Abbildung 7: WebRTC Chatanwendung [1]

5. WebRTC Leak

Die relevanteste Sicherheitslücke im Zusammenhang mit WebRTC ist der IP-Leak [17], hierbei kann trotz Nutzung eines VPNs mithilfe der WebRTC API die öffentliche sowie private IP ausgelesen werden. Dies beeinträchtigt erheblich die Privatsphäre, da Rückschlüsse auf die Identität des Benutzers geschlossen werden können. WebRTC benötigt zur korrekten Kommunikation die private IP-Adresse, diese kann durch eine JavaScript Anfrage an den STUN-Server ermittelt werden, was Sicherheitsmechanismen wie Firewalls oder VPNs umgeht. Die einfachste Mitigation ist das Blockieren von WebRTC im Browser, hierfür werden Browserplugins sowie Privatsphäre Einstellungen bereitgestellt. Die Abbildung 8 zeigt die betroffenen Browser auf dem Betriebssystem Windows zum Stand 2017.

Abbildung 8: WebRTC Leak [17]

6. Fazit

WebRTC ist die am meisten fortgeschrittene Standardisierung von Echtzeit Peer-to-Peer Kommunikation, welche von fast allen Plattformen unterstützt wird. Durch den Open Source Charakter entwickelt sich die Technologie rasant weiter und wird in zahlreichen kommerziellen Softwareprodukten genutzt. Die kostenlose Benutzung und die Möglichkeit des Verzichtes auf zusätzliche Hardware und Software, macht die Implementierung attraktiv und einfach. Der Peer-to-Peer Standard sowie die zusätzliche Verschlüsselung durch DTLS hebt WebRTC als einen der sichersten Kommunikationsstandards auf den Markt heraus. Durch die aktive Weiterentwicklung von Google sowie einer großen Community an Freiwilligen wird WebRTC auch in Zukunft für immer mehr Anwendungsfälle einsetzbar werden. Diese beinhalten vor allem die Bereiche IoT, Gaming, Machine Learning und File Sharing. [1][18]

Abkürzungsverzeichnis

API Application Programming Interface

CSS Cascading Style Sheets

DTLS Datagram Transport Layer Security

HTML Hypertext Markup Language

HTTP Hypertext Transfer Protocol

HTTPS Hypertext Transfer Protocol Secure

ICE Interactive Connectivity Establishment

IETF Internet Engineering Task Force

IoT Internet of Things

IP Internet Protocol

JSEP JavaScript Session Establishment Protocol

NAT Network Address Translation

PHP Hypertext Preprocessor

RTCP Real-Time Control Protocol

RTP Real-Time Transport Protocol

SCTP Stream Control Transmission Protocol

SDP Session Description Protocol

SIP Session Initiation Protocol

SRTP Secure Real-Time Transport Protocol

STUN Simple Traversal of User Datagram Protocol Through NAT

TCP Transmission Control Protocol

TLS Transport Layer Security

TURN Traversal Using Relays around NAT

UDP User Datagram Protocol

URI Uniform Resource Identifier

URL Uniform Resource Locator

VoIP Voice over IP

VPN Virtual Private Network

W3C World Wide Web Consortium

WebRTC Web Real-Time Communication

XHR XMLHttpRequest

XML Extensible Markup Language

XMPP Extensible Messaging and Presence Protocol

Literaturverzeichnis

B. Sredojev, D. Samardzija and D. Posarac, WebRTC technology overview and signaling solution design and implementation, 2015 38th International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO), 2015, pp. 1006-1009, doi: 10.1109/MIPRO.2015.7160422.
Alvestrand, H. (2017, 12. November). draft-ietf-rtcweb-overview-19. Www..Ietf.Org. https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-overview
Hickson, I. (2021, 26. Januar). WebRTC 1.0: Real-Time Communication Between Browsers. Www.W3.Org. https://www.w3.org/TR/webrtc/
Levent-Levi, T. (2020, 24. Dezember). 10 Massive Applications Using WebRTC. BlogGeek.Me. https://bloggeek.me/massive-applications-using-webrtc/
Dietmar Abts, Masterkurs Client/Server-Programmierung mit Java. ISBN 978-3-8348-0322-1 [Titel anhand dieser ISBN in Citavi-Projekt übernehmen] .Alle Rechte vorbehalten. Friedr. Vieweg & Sohn Verlag / GWV Fachverlage GmbH, 2007
Hauswirth, Manfred and Schahram Dustdar. "Peer-to-Peer: Grundlagen und Architektur." Datenbank-Spektrum 13 (2005): 5-13.
Holmberg, C., Hakansson, S. & Eriksson, G. (2015, März). rfc7478. Www.Ietf.Org. https://datatracker.ietf.org/doc/html/rfc7478
Loreto, S. & Romano, P. S. (2014). Real-Time Communication with WebRTC: Peer-to-Peer in the Browser (1. Aufl.). O'Reilly and Associates.
Mozilla. (2021, 28. April). Media Capture and Streams API (Media Stream) - Web APIs | MDN. Developer.Mozilla.Org. https://developer.mozilla.org/en-US/docs/Web/API/Media_Streams_API
Alexander, Andre & Wijesinha, Alexander & Karne, Ramesh. (2009). An evaluation of Secure Real-Time Transport Protocol (SRTP) performance for VoIP. 95-101. 10.1109/NSS.2009.90 [Titel anhand dieser DOI in Citavi-Projekt übernehmen] .
Jesup, R., Loreto, S. & Tuexen, M. (2015, 4. Januar). draft-ietf-rtcweb-data-channel-13. Datatracker.Ietf.Org. https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-data-channel
Li, J.-K & Sun, S.-X. (2002). The study and realization of NAT technology. 29. 324-328.
Handley, M., Jacobson, V. & Perkins, C. (2006, Juli). rfc4566. Ietf.Org. https://datatracker.ietf.org/doc/html/rfc4566
Uberti, J., Jennings, C. & Rescorla, E. (2019, 27. Februar). draft-ietf-rtcweb-jsep-26. Ietf.Org. https://datatracker.ietf.org/doc/html/draft-ietf-rtcweb-jsep
Crowcroft, J. (1999). Session Description Protocol (SDP). In M. Handley & I. Wakeman (Hrsg.), Internetworking Multimedia (S. 134–135). Morgan Kaufmann.
Badach, Anatol. (2010). DTLS – Datagram Transport Layer Security. 10.13140/RG.2.1.1790.3124 [Titel anhand dieser DOI in Citavi-Projekt übernehmen] .
N. M. Al-Fannah, "One leak will sink a ship: WebRTC IP address leaks," 2017 International Carnahan Conference on Security Technology (ICCST), 2017, pp. 1-5, doi: 10.1109/CCST.2017.8167801 [Titel anhand dieser DOI in Citavi-Projekt übernehmen]
Superstar, A. (2021, 12. April). The Past, Present, and Future of WebRTC. Agora. https://www.agora.io/en/blog/past-present-future-of-webrtc/