8. Security Considerations (Sicherheitsüberlegungen)

8. Security Considerations (Sicherheitsüberlegungen)

Die IETF hat separate Dokumente [RFC8827] [RFC8826] veröffentlicht, die die Sicherheitsarchitektur für WebRTC als Ganzes beschreiben. Der Rest dieses Abschnitts beschreibt die Sicherheitsüberlegungen für dieses Dokument.

Obwohl die JSEP-Schnittstelle formal eine API ist, ist es besser, sie als Internetprotokoll zu betrachten, wobei das Anwendungs-JavaScript aus der Perspektive der JSEP-Implementierung als nicht vertrauenswürdig angesehen wird. Daher gilt das Bedrohungsmodell von [RFC3552]. Insbesondere kann JavaScript die API in beliebiger Reihenfolge und mit beliebigen Eingaben aufrufen, einschließlich böswilliger Eingaben. Dies ist besonders relevant, wenn wir das SDP betrachten, das an setLocalDescription übergeben wird. Während die korrekte API-Verwendung erfordert, dass die Anwendung SDP übergibt, das von createOffer oder createAnswer abgeleitet wurde, gibt es keine Garantie dafür, dass Anwendungen dies tun. Die JSEP-Implementierung MUSS darauf vorbereitet sein, dass JavaScript stattdessen gefälschte Daten übergibt.

Umgekehrt muss sich der Anwendungsprogrammierer bewusst sein, dass JavaScript keine vollständige Kontrolle über das Endpunktverhalten hat. Ein Fall, der besondere Erwähnung verdient, ist, dass das Entfernen von ICE-Kandidaten aus dem SDP oder das Unterdrücken von getrickelten Kandidaten nicht das erwartete Verhalten hat: Implementierungen werden immer noch Prüfungen von diesen Kandidaten durchführen, auch wenn sie nicht an die andere Seite gesendet werden. Daher ist es beispielsweise nicht möglich, zu verhindern, dass der entfernte Peer Ihre öffentliche IP-Adresse erfährt, indem server-reflexive Kandidaten entfernt werden. Anwendungen, die ihre öffentliche IP-Adresse verbergen möchten, MÜSSEN stattdessen den ICE-Agenten so konfigurieren, dass er nur Relay-Kandidaten verwendet.