Ich würde meine Streams gerne über https einspeisen um das abfischen von Passwörtern zu erschweren.
Ich möchte zukünftig mit einem zentralen Benutzermanagement arbeiten und damit wären meine User Credentials in Gefahr und jemand der diese Daten abfischt, hätte sofort Zugriff auf sämtliche Ressourcen des Moderators.
Sobald ich aber https:// vor meinen Hostnamen/IP schreibe, schlägt die Encoderverbindung mit BASS Error -1 fehl. Port wurde von 80 auf 443 geändert.
Icecast Server Version ist 2.4.4, TLS Zertifikat ist von Let’s Encrypt und funktioniert für die Auslieferung der Streams. Da Einspeisung und Auslieferung bei Icecast quasi gleich behandelt werden, würde ich sagen, dass auch eine https Einspeisung funktionieren müsste.
Gibt es eigentlich irgend welche Encoder mit denen man die Grundsätzliche Serverfunktionalität https nachweisen könnte?
Das ist alles in der bassenc.dll, also außerhalb meines Einflussbereiches. Man müsste bei Ian (www.un4seen.com) nachfragen, ob das überhaupt technisch möglich und ggf. bereits in Planung ist.
Mein letzter Stand ist aber, dass man von Icececast/Shoutcast-Streams per https die Finger lassen sollte, da es noch zu viele Clients (auf Hörerseite) gibt, die das gar nicht unterstützten.
[quote=“Torben, post:2, topic:12032”]Das ist alles in der bassenc.dll, also außerhalb meines Einflussbereiches. Man müsste bei Ian (www.un4seen.com) nachfragen, ob das überhaupt technisch möglich und ggf. bereits in Planung ist.
Mein letzter Stand ist aber, dass man von Icececast/Shoutcast-Streams per https die Finger lassen sollte, da es noch zu viele Clients (auf Hörerseite) gibt, die das gar nicht unterstützten.[/quote]
Dass es diese Probleme auf Hörerseite gibt, ist mir bewusst. Der Stream wird bei uns deshalb auch sowohl als auch ausgeliefert. Aufgrund der immer schärfer werdenden Browser Policies bezüglich http content, hatte ich eher Probleme, weil ich nicht überall https Streams hatte. Es gibt aber reichlich alte IP Radios und vermutlich auch Software Player, die kein https können, das ist absolut richtig und das muss man auf dem Schirm haben.
Beim Hörer werden ja auch keine Login Credentials übertragen. Ich könnte lediglich als Man in the Middle versuchen Shadcode einzuschleusen. Dazu muss ich aber das Ziel beim Hörer schon sehr genau kennen um da wirklich z.B. ein IP Radio angreifen zu können. Was durchaus Sinn machen kann, denn ich vermute, bei den meisten werden WiFi Daten nicht besonders gut geschützt sein.
Es geht mir hier also nur um die Einspeisung.
Letztendlich mache ich als Source ja nur eine http basic auth mit unverschlüsselt übertragenen credentials. Das ist ziemlich leicht abzugreifen.
Wenn ich hier Serverseitig die Auth Hooks von Icecast nutzen möchte, wird das schon zu einem ziemlichen Sicherheitsrisiko, weil ich keine Möglichkeit habe, die Credentials in irgend einer Form zu schützen.
Der gleiche Basic Auth über https ist nicht 100% sicher aber schon deutlich mehr Aufwand notwendig um die Daten abzufischen.
Betrifft auch Dein eines eventuelles Projekt, über das wir uns mal ausgetauscht hatten… Wäre auch dort ein Angriffsszenario.
Welche anderen Workarounds gäbe es, wenn ich tatsächlich nicht https einspeisen kann?
Das Passwort selber noch mal verschlüsseln, so eine art Auth Token daraus machen?