WebRTC P2P

Bei der Arbeit für Live Event Netzwerk habe ich gelernt, dass in Verbindung mit dem Microsoft eCDN eine P2P-Verbindung zwischen Clients aufgebaut werden kann. Das ist im Prinzip nichts neues, wenn Sie in Microsoft Teams schon 1:1 Gespräche geführt haben. Aber haben wir hier ein Risiko?

N:1 und 1:1

Auf der einen Seite sind die Clients und auf der anderen Seite der Service. In der Regel kommunizieren viele Clients mit den bekannten DNS-Namen und Ports, z.B. 443/HTTPS oder 5061/SIP miteinander. Eine direkte Verbindung zwischen Client kommt meist nicht vor und P2P-Netzwerke wie eMule, Bittorrent u.a. kennen meist eher die älteren IT-Kundigen. In de VoIP-Welt war es aber schon immer üblich, dass auch Clients direkt miteinander kommunizieren, wen es denn möglich ist. Wenn zwei VoIP-Telefone in einem gerouteten Netzwerk eine Audio-Verbindung aufgebaut haben, dann konnten Sie die Pakete auch direkt zur Gegenstelle senden ohne über ein Relay (STUN/TURN) zu gehen. Das ist allerdings eigene Hardware oder eine vom Administrator auf einem PC installierte eigene Software.

Nun wissen wir aber, dass es heute keine kompilierte EXE-Datei mehr benötigt, sondern immer mehr Programme als "Modern App" einfach im Browser laufen, d.h. die Anzeige ist  HTML/CSS und die Logik wird in JavaScript bereitgestellt. So können Sie Microsoft Teams direkt im Browser ohne weitere Installation starten und darüber sogar andere Teams-Teilnehmer per Audio/Video anrufen. Spätestens hier muss ihnen auffallen, dass hier die Clients nicht nur Daten senden sondern auch empfangen können und nicht nur ein Handshake möglich ist sondern sogar Ports geöffnet werden, ohne dass die Windows Firewall hier anschlägt.

Dies fällt insbesondere bei Teams Live Events in Verbindung mit dem Microsoft eCDN auf, wenn viele Personen in einem Standorte einem Live Event folgen und die Bandbreite durch diesen P2P-Option geschont wird.

WebRTC Docs

WebRTC ist ein Baustein im Browser, mit dem ein Client mit einer Gegenstelle einen Kanal öffnen kann. Das kann ein Browser per HTTPS auch, aber nun kann der Browser auch selbst „Server“ sein und das könnte ganz neue Angriffsmuster für P2P-Virenverbreitung öffnen. Sie haben richtig gelesen. Ihr Browser kann einen eingehenden Port öffnen und diese Information z.B. über eine zentrale Clearing-Stelle einer Gegenseite mitteilen, die dann Daten auf diesen gerade geöffneten Zugang sendet.

Das ganze Verfahren ist aber relativ gut dokumentiert und es gibt auch erste JavaScript-Libraries, um diese neuen Verbindungen einfach nutzen zu können:

Wer nutzt WebRTC

Der Name "WebRTC" setzen viele Personen mit "Web" für Internet und "RTP" für "Real Time Protocol" gleich und erwarten, dass WebRTC für Audio und Video-Verbindungen genutzt wird. Entsprechend nutzen mittlerweile auch fast alle Konferenzplattformen auch WebRTC, wenn der Client im Browser läuft. Die Produkte kommen so ohne PlugIns aus, die wieder Browserspezifisch und Betriebssystemspezifisch sind. Eine Auflistung solcher Produkte erspare ich mir.

Aber WebRTC ist nicht auf Audio/Video beschränkt und sehr viel andere Produkte nutzen ebenfalls den Stack, insbesondere wenn die Applikation selbst auch im Browser läuft, Das können Brwoser-Versionen sein, die eine Verbindung zu einer App auf dem Smartphone herstellen.

Achten Sie bei der Installation solcher Produkte darauf, dass diese als Administrator installiert werden und damit entsprechende Firewall-Regeln eingetragen werden können.

Dies ist nicht erforderlich, wenn die Applikation gar nicht klassisch installiert wird, sondern nur im Browsers als ModernApp ausgeführt wird.

P2P und Security

Damit stellt sich natürlich die Frage, wie dies hinsichtlich der Sicherheit aussieht. WebRTC erlaubt meines Wissens kein "Suchen" im Netzwerk nach kommunikationsbereiten Systemen über Broadcasts oder Multicasts und das wäre auch nicht wirklich sinnvoll. Peer2Peer ist nicht an ein Subnetz beschränkt und eine Suche über Subnetzgrenzen hinweg funktioniert nicht. Aber es gibt zwei andere Wege, wie sich Endpunkte finden:

  • Vermittlungsserver
    Ein WebRTC-Anwendung wird als HTML/CSS/JS-Dadei in der Regel von einem Webserver geladen. Dieser Service ist damit dem Client bekannt und er kannt dort auch Informationen über seine IP-Adressen und Ports senden. Über den Weg können zwei Systeme ihr Kandidaten austauchen.
  • mDNS
    Ein zweiter Weg ist die Registrierung des Clients über mDNS (Multicast). Dann können Sie z.B. einen zufälligen mDNS-Namen austauschen und damit IP-Adressen verbergen.

Hinweis: Wenn die beiden Clients sich nicht direkt erreichen können und stattdessen über STUN/TURN kommunizieren müssen, dann müssen Sie natürlich auch einen solchen Service mit anbieten.

In allen Fällen muss WebRTC natürlich einen Port öffnen können. Je nach der lokal installierten Sicherheitslösung ist dies vielleicht nicht möglich. Gerade auf "zugestopften" Clients müssen Sie entsprechende Ausnahmen für die verwendeten Browser einrichten, wenn sie eine direkte WebRTC-Kommunikation zwischen zwei Client erlauben wollen.

Wenn der WebRTC ein eigeneständig ausführbares Programm wie z.B. "Teams.exe" ist, dann kann die Desktop Firewall auch kontrolliere, welche Ports die jeweilige Applikation öffnen darf. Startet die Applikation aber als ModernApp im Browser, dann sieht das Betriebssystem und eine darauf installierte Firewall nur den Browser als Client. Eine Steuerung, welche Applikation geladen werden darf, kann dann nur über den Internetzugang oder zusätzliche Schutzmodule im Browser (z.B. Microsoft Defender) erfolgen, die hier in den WebRTC aufruf eingreifen.

WebRTC Demo

Auch wenn viele Produkte schon WebRTC aufsetzen und sie vermutlich schon damit gearbeitet haben, sind dies dennoch keine "schönen" Beispiele. Um aber den Vorteil einer lokalen WebRTC-Funktion bei sehr großen Meetings zu demonstrieren, hat Microsoft eine Testseite aufgesetzt. Unter der folgenden URL wird das Video "Big Bucks Bunny" abgespielt, welches der Browser vom Azure CDN bezieht. Das ist an sich noch nichts besonderes:

Microsoft eCDN Tester
https://aka.ms/ecdn/tester

Interessant wird es, wenn Sie diese URL auf mehreren Computern starten oder in mehreren Karteikarten auf dem gleichen Computer. Wenn WebRTC korrekt funktioniert, dann sollte die verwendete App an das Backend seinen Status melden und Microsoft vermutlich anhand der gleichen öffentlichen IP-Adresse erkennen, welche Clients eventuell in einem gerouteten IP-Netzwerk sind. Dann versuchen die Client ihre Daten von einem anderen Client zu beziehen, der die gleiche Information schon früher erhalten hat.

Wenn Sie eine eCDN-Lizenz haben, können Sie sogar einen "Silent Test" mit ihren Clients machen.

Einschätzung

WebRTC hat schon lange den Experimentierstatus verlassen und wird in vielen Produkten in Verbindung mit passenden Servern im Backend zur Verbindungssteuerung eingesetzt. Eine direkte P2P-Verbindung zwischen zwei Endpunkten im gleichen Netzwerk wird ebenfalls z.B. für VoIP-Verbindungen, Verbindungen zu internen Servern oder Steuerung von Smartphones genutzt.

Microsoft hat mit seinem eCDN die Latte noch einmal deutlich höher gelegt, denn hier kann ein Client seine im Live Event empfangene Information an weitere Clients im gleichen Netzwerk weitergeben und damit deutlich Bandbreite am Internet-Zugang einsparen.

Ein Sicherheitsrisiko ist natürlich denkbar, da auch eine Malware über WebRTC z.B. Daten mit "Partnern" im gleichen Netzwerk oder Internet austauschen kann. Sie sollten an der Firewall schon ein Auge darauf haben, zu welchen Gegenstellen eine WebRTC-Verbindung aufgebaut wird. Denn letztlich ist jede RTC oder WebRTC-Verbindung immer eine 1:1 Verbindung zwischen zwei Systemen. Und hier können und sollten Se ein Auge drauf haben, z.B. Firewall-Logs ins Internet oder auch intern durch NetFlow/sFlow/IPFix/cFlow u.a.

Weitere Links