PDF File
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.
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.
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.
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]
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.
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.
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.
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.
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.
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]
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.
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]
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.
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]
API Application Programming Interface
CSS Cascading Style Sheets
DTLS Datagram Transport Layer Security
DTLS Datagram Transport Layer Security
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICE Interactive Connectivity Establishment
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
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