WebRTC

January 29, 2020tutorial

WebRTC = Web Real-Time Communication, deutsch „Web-Echtzeitkommunikation“
Offener Standard, definiert Protokolle und API
Frei und Open Source
Peer-to-Peer Verbindungen, d.h. direkte Verbindungen ohne Server => Von Browser zu Browser
Übertragung von Daten, Video und Audio
Seit Anfang der 2010er Jahre. Treibende Kraft Google, nach aufkauf der Firma Global IP Solutions. Aber auch Mozilla und Opera.
Teil des Standards: Datenströme müssen immer verschlüsselt sein (Details siehe [2] [3] [4])
Aktuelle Verfügbarkeit von fast 94% aller Internetteilnehmer (Quelle caniuse.com)
Homepage: webrtc.org
Offizieller Standard seit Dienstag :)

Bausteine

Signaling

Bevor Peers sich direkt verbinden können, müssen sie über einen gemeinsamen Knoten miteinander bekannt gemacht werden.
Das geschieht üblicherweise über einen kleinen Websocket Server mit dem dann Teilnehmer eines "Raumes" miteinander bekannt gemacht werden
Eine extrem einfache Implementierung findet sich hier: https://gist.github.com/holtwick/d10baa8123b4b704a86dd052aecf0b70

Jeder Peer muss zunächst seine eigene Adresse im Netz feststellen, um sie mitteilen zu können.
- Der einfachste Fall wäre eine IP und ein Port.
- Hinter einer Firewall/NAT wird ein sog. STUN Server angerufen, der den Weg auflöst (NAT Traversal)
- Klappt alles das nicht, können über einen TURN Server als Proxy die Daten ausgetauscht werden
- Diese Information ist standardisiert als SDP (Session Description Protocol)
Über den Signaling Layer werden nun die gewonnen Informationen untereinander ausgetauscht und eine sichere direkte Verbindung aufgebaut
Das verwendete Protokoll heißt ICE (Interactive Connectivity Establishment)

Über die nun bestehende Verbindung lassen sich nun bi-direktional Daten und Streams austauschen
Im Browser können über getUserMedia Audio- und Video-Streams bezogen werden, die dann gestreamt werden können
- Durch bestimmte Einstellungen können die Qualität und bevorzugte Geräte (z.B. Vorder- oder Rückkamera eines Mobilgerätes) ausgewählt werden
- In den meisten Browsern ist es möglich auch den Inhalt des Desktops oder einzelner Fenster zu teilen

Signaling muss sicher ablaufen, um eine Manipulation der SDP Daten zu verhindern (MitM - Man in the Middle Attacke)
- Immer SSL verwenden
- Entwender den Benutzer durch Anmeldung authentifizieren, oderdie Daten Ende-zu-Ende verschlüsseln
- Fingerprints der WebRTC Verbindung vergleichen
Jeder Peer muss einen eigenen Datenstrom zu jedem anderen Peer aufbauen, d.h. bei x Teilnehmern gibt es x-1 ausgehende und x-1 eingehende Verbindungen
- Das kann bei mehreren Teilnehmern zu einem Problem werden (ab ca. 8-10 User)
- Alternativ kann eine SFU eingesetzt werden, die die Signale sternförmig an alle User verteilt. (10-50 User)
  - Nachteil: In der Regel in der SFU nicht mehr verschlüsselt, d.h. dem Server muss vertraut werden können; neuere Browser erlauben E2E Verschlüsselung mittels "Insertable Streams"
- Mit einer MCU können die Datenströme weiter reduziert werden, indem Video und Audio-Streams in einen Gesamtstream gemischt werden. Das erfordert erhebliche Resourcen auf dem Server und eine E2E Verschlüsselung ist technisch nicht mehr möglich.
Störungen könnten an verschiedenen Stellen auftreten: Webservice, Signalserver, STUN, TRUN, SFU
Der Browser des Benutzers könnte leicht zugänglich sein und somit komromitierende Daten von Dritten dort aufgefunden werden: Datenhygiene auch auf Client-Seite erforderlich, z.B. keine automatische Einwahl ohne Authentifizierung etc.