Ich mach Pause von Kodi

Du verwechselst da eventuell was. Ein VPN ist authentifiziert und verschlüsselt. Da kann auch gar kein Passwort in TV Headend gesetzt sein und man greift trotzdem auch aus einem öffentlichen WLAN über VPN sicher drauf zu ohne die Gefahr einer MITM-Attacke. HTTPS dagegen authentifiziert nicht sondern verschlüsselt nur. Das hilft in einem öffentlichen WLAN gegen MITM aber wenn jemand die URL kennt, kann er trotzdem auf den Dienst zugreifen, was bei VPN nicht möglich ist.

Zitat von jkdask

Ein VPN ist authentifiziert und verschlüsselt. Da kann auch gar kein Passwort in TV Headend gesetzt sein und man greift trotzdem auch aus einem öffentlichen WLAN über VPN sicher drauf zu ohne die Gefahr einer MITM-Attacke.

Das gilt aber auch nur, wenn der Client ein Zertifikat des Servers hat. Also entweder wenn man dem Server ein WebPKI Zertifikat gegeben hat, oder man muss den Client nicht nur mit seinem username/passwort konfigurieren, sondern auch dem Zertifikat des Servers.

Zitat von jkdask

HTTPS dagegen authentifiziert nicht sondern verschlüsselt nur. Das hilft in einem öffentlichen WLAN gegen MITM aber wenn jemand die URL kennt, kann er trotzdem auf den Dienst zugreifen, was bei VPN nicht möglich ist.

Du hast bei HTTPs die Option das der Client sich nicht authentifizeren muss. Das ist das was man normalerweise bei Webseiten im Internet macht. Aber man kann da auch normale HTTP authentication mit dazu konfigurieren, das ist dann wie VPN. Oder aber die Authentifizierung ist halt in der Webanwendung selbst, also wenn man z.b. in TVH username/passwort konfiguriert. Da kriegt man natuerlich wie auch bei Webseiten normalerweise zuerst eine login-webpage zu sehen. Das kann dann etwas sein was man will, oder vielleicht auch nicht.

Zitat von te36

Das gilt aber auch nur, wenn der Client ein Zertifikat des Servers hat. Also entweder wenn man dem Server ein WebPKI Zertifikat gegeben hat, oder man muss den Client nicht nur mit seinem username/passwort konfigurieren, sondern auch dem Zertifikat des Servers.

Bei welchem VPN-Tool werden Zugangsdaten unverschlüsselt übertragen? Mir ist keines bekannt. Bei WireGuard haben beide Seiten Private- oder Public-Keys. OpenVPN nutzt Zertifikate und auch bei IPSec findet keine unverschlüsselte Kommunikation statt. Insofern kann ich dein Argument nicht ganz nachvollziehen.

Zitat von te36

Du hast bei HTTPs die Option das der Client sich nicht authentifizeren muss.

Man hat nicht die Option, sich nicht zu authentifizieren sondern hat die Option, sich beispielsweise über HTTP Basic Auth zu authentifizieren. Du hast aber bisher von HTTPS gesprochen und nicht davon, gleichzeitig auch eine zusätzliche Authentifizierung zu nutzen. Wenn man das einsetzt, muss es aber auch vom entsprechenden Kodi Addon unterstützt werden, weil man sonst nicht viel weiter ist. Bei HTTP Basic Auth mag das mit Glück noch der Fall sein, bei TLS Mutual Auth (TLS mit Client-Zertifikat) eher unwahrscheinlich.

Gerade durch die unkompliziertes Einrichtung auf einer Fritz Box würde ich WireGuard für den Anwendungsfall vorziehen. Man braucht wahrscheinlich auch nicht unbedingt ein Addon für CE. Es könnte reichen, wenn das iPhone der Hotspot ist und gleichzeitig über WireGuard mit der Fritz Box verbunden ist. Insofern geht es kaum einfacher und sicherer.

Zitat von jkdask

Bei welchem VPN-Tool werden Zugangsdaten unverschlüsselt übertragen? Mir ist keines bekannt. Bei WireGuard haben beide Seiten Private- oder Public-Keys. OpenVPN nutzt Zertifikate und auch bei IPSec findet keine unverschlüsselte Kommunikation statt. Insofern kann ich dein Argument nicht ganz nachvollziehen.

Ich meinte nicht, das bei einem VPN die Authentifizierung unverschluesselt ist, sondern das da halt der Aufwand die credentials zwischen client und server auszutauschen auch nicht anders ist, als wenn man z.b. TLS verwendet. Also wie man passwoerter/zertifikat/public-key austauscht.

Jo, was theoretisch geht, und was dann client/server praktisch unterstuetzen sind zwei Welten. Ich bin halt bisher soweit gekommen, das ich caddy mit https und automatischen Zertifikat ueber Internet laufen habe und damit dann von irgendeinem client, kodi, vlc, browser vom internet aus einfach nur per https url mit basic auth auf die medien zugreifen kann.auf z.b. aufgezeichnete medien schoen per https url mit username/passwort (basic auth) vom Kodi clients oder vlc oder so. Das mit (reverse) proxy muss ich hoffentlich demnaechst mal probieren.

[quote='jkdask','https://www.kodinerds.net/index.php/Thre…3888#post713888']Gerade durch die unkompliziertes Einrichtung auf einer Fritz Box würde ich WireGuard für den Anwendungsfall vorziehen. Man braucht wahrscheinlich auch nicht unbedingt ein Addon für CE. Es könnte reichen, wenn das iPhone der Hotspot ist und gleichzeitig über WireGuard mit der Fritz Box verbunden ist. Insofern geht es kaum einfacher und sicherer.

Hatte ich ja gesagt - kommt immer drauf an, ob/wie das einrichten des VPN clients ein Problem ist...

Top...

Ende gut, alles gut

Einen kleinen Nachtrag aus meiner Erfahrung, als ich im Zuge dieses Threads mir meine Dienste und deren Erreichbarkeit aus dem Netz angeguckt habe.

Ich nutze auch TVHeadend zum streamen nach extern, allerdings auf Ubuntu, also habe ich zumindest das „Root“-Problem nicht. VPN wäre die beste Lösung, aber wollte ich aufgrund der Vielzahl der Clients erstmal nicht.

Mein Ziel: das WebIF und die Config von TVHeadend sollten nur aus dem internen Netzwerk mit einem Admin-Account erreichbar sein und nicht von außen. Der Streaming-User sollte keinen Zugriff auf die Konfiguration von TVHeadend haben.

Egal was ich eingestellt habe: es hat nicht funktioniert. Der Streaming User hatte immer noch Konfiguration-Rechte, auch wenn „Admin“ oder „Web Interface“ deaktiviert waren.

Lösung: TVHeadend legt oder legte (meine Konfiguration ist mehrere Jahre alt) eine Datei …/.hts/tvheadend/superuser an. Dieser User hat Admin-Rechte und taucht im WebIf nicht auf. Das Passwort und der Name sind im Klartext (!!!) gespeichert. Zugriff hat nur root. Bei mir war es so, dass User und Passwort mit meinem Streaming-User übereinstimmten und der deswegen Zugriff hatte und die Einstellungen im WebIf ignoriert wurden.

Ich halte das Anlegen einer Textdatei mit Admin-Rechten im Klartext für fahrlässig. Ich kann nicht rekonstruieren, ob das Standard ist oder ob das mal von einem bestimmten Wizard / Version angelegt wurde. Im Netz findet man wenig dazu, aber prüft es besser mal bei euren Installationen.

Bei mir geht’s jetzt wie gewünscht (habe die Datei entfernt…lieber installiere ich neu, wenn mein Passwort weg ist). Von außen keine Konfigurationszugriff mehr. VPN kommt als nächstes.

Danke für den Thread nochmal!

Zitat von tojo2503

TVHeadend legt oder legte (meine Konfiguration ist mehrere Jahre alt) eine Datei …/.hts/tvheadend/superuser an. Dieser User hat Admin-Rechte und taucht im WebIf nicht auf. Das Passwort und der Name sind im Klartext (!!!) gespeichert. Zugriff hat nur root.

Mein TVH ist zwar nur intern und nicht nach außen offen, aber du hast Recht, diese Datei habe ich auch.

Zitat von tojo2503

Einen kleinen Nachtrag aus meiner Erfahrung, als ich im Zuge dieses Threads mir meine Dienste und deren Erreichbarkeit aus dem Netz angeguckt habe.

Ich nutze auch TVHeadend zum streamen nach extern, allerdings auf Ubuntu, also habe ich zumindest das „Root“-Problem nicht. VPN wäre die beste Lösung, aber wollte ich aufgrund der Vielzahl der Clients erstmal nicht.

Mein Ziel: das WebIF und die Config von TVHeadend sollten nur aus dem internen Netzwerk mit einem Admin-Account erreichbar sein und nicht von außen. Der Streaming-User sollte keinen Zugriff auf die Konfiguration von TVHeadend haben.

Egal was ich eingestellt habe: es hat nicht funktioniert. Der Streaming User hatte immer noch Konfiguration-Rechte, auch wenn „Admin“ oder „Web Interface“ deaktiviert waren.

Lösung: TVHeadend legt oder legte (meine Konfiguration ist mehrere Jahre alt) eine Datei …/.hts/tvheadend/superuser an. Dieser User hat Admin-Rechte und taucht im WebIf nicht auf. Das Passwort und der Name sind im Klartext (!!!) gespeichert. Zugriff hat nur root. Bei mir war es so, dass User und Passwort mit meinem Streaming-User übereinstimmten und der deswegen Zugriff hatte und die Einstellungen im WebIf ignoriert wurden.

Ich halte das Anlegen einer Textdatei mit Admin-Rechten im Klartext für fahrlässig. Ich kann nicht rekonstruieren, ob das Standard ist oder ob das mal von einem bestimmten Wizard / Version angelegt wurde. Im Netz findet man wenig dazu, aber prüft es besser mal bei euren Installationen.

Bei mir geht’s jetzt wie gewünscht (habe die Datei entfernt…lieber installiere ich neu, wenn mein Passwort weg ist). Von außen keine Konfigurationszugriff mehr. VPN kommt als nächstes.

Danke für den Thread nochmal!

Alles anzeigen

Diese Datei Superuser wird vom Debian/Ubuntu Installer angelegt und sorgt halt dafür das die Weboberfläche nicht direkt nach dem Start offen wie ein Scheunentor ist.
Hat also nichts damit zu tun wie alt deine Installation ist etc, sondern am zugrundeliegende OS.
Das User und Pass darin im Klartext stehen ist zwar nicht schön (Passwort zu hashen ist jetzt auch keine Kunst), aber die Datei liegt im Homeverzeichnis des User hts und dort kommt man nicht ohne weiteres dran. Wenn ich da dran komme dann bin ich eh schon im System.

Die Lösung ist jedenfalls besser als TVH mit dem Parameter -C zu starten der dafür sorgt das ein Superadmin ohne Passwort und Beschränkungen angelegt wird.

Zitat von darkside40

Diese Datei Superuser wird vom Debian/Ubuntu Installer angelegt und sorgt halt dafür das die Weboberfläche nicht direkt nach dem Start offen wie ein Scheunentor ist.Hat also nichts damit zu tun wie alt deine Installation ist etc, sondern am zugrundeliegende OS.
Das User und Pass darin im Klartext stehen ist zwar nicht schön (Passwort zu hashen ist jetzt auch keine Kunst), aber die Datei liegt im Homeverzeichnis des User hts und dort kommt man nicht ohne weiteres dran. Wenn ich da dran komme dann bin ich eh schon im System.

Die Lösung ist jedenfalls besser als TVH mit dem Parameter -C zu starten der dafür sorgt das ein Superadmin ohne Passwort und Beschränkungen angelegt wird.

Allse klar, danke für die Aufklärung. Bei mir kam halt dazu, dass der superuser aus der Datei und mein lokaler User exakt identisch waren und ich keine Ahnung hatte, dass es überhaupt einen superuser gibt. Das hat mich dann doch sehr verwirrt.
Aber nach deiner Erklärung: ja, das ist so besser als ohne Passwort.

Viele Grüße