Beiträge von jkdask

    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.

    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.

    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.

    @te36 Okay also zusammengefasst hätte es im vorliegenden Fall wenig bis gar nichts gebracht, da es sich augenscheinlich nicht um eine MITM-Attacke handelte. Nichtsdestotrotz macht es natürlich Sinn, über das Internet erreichbare Dienste mit einer Transportverschlüsselung zu versehen.

    Bei der Ersteinrichtung wird man durch den Einrichtungsassistenten geführt. Den kann man abbrechen (noch vor der Vergabe eines Passworts für root) - mit dem Ergebnis, dass man sich als root ohne Authentifizierung anmelden kann. Bumm, drin.

    Nutze TVH nicht aber das habe ich dem Thema schon entnehmen können. Es hilft aber nur was, da was umzuschreiben, wenn das dann auch im Repo von LE/CE landet. Ansonsten ist damit ja niemandem geholfen.

    Podman ist quasi ein Drop In Replacement für Docker und hat das gleiche CLI und unterstützt auch Composer. Ich kann es momentan noch nicht verwenden weil eine App noch Docker erfordert aber würde es sonst auch nutzen.

    @DaVu nur wenn du user explizit der Gruppe docker hinzufügst. Ansonsten können normale User keine Container starten. Und es gibt eigentlich keinen Grund, warum man irgendwas aus etc vom host in den Container mounten würde.

    Das Problem ist überschaubar. Was DaVu meint ist dass wenn der Docker Daemon als root läuft, mal beliebige Pfade des Dateisystems da rein mounten kann und eben dort im Container lesen und schreiben kann.

    Normalerweise kann nur root überhaupt Container starten außer man erlaubt das explizit auch anderen Benutzern. Man auch den Docker Daemon rootless benutzen mit ein paar Einschränkungen. So oder so braucht ein Angreifer erstmal Zugriff auf den Host, um den von DaVu beschriebenen Angriff auszuführen.