FTP Media Source über Auth-SSL/TLS

Rhino Cracker

Hi zusammen,

ich hab ein paar Probleme dabei, meine FTP-Quelle einzubinden.
Ich möchte sie über Auth-SSL oder Auth-TLS mit verschlüsseltem Kommando-, OrdnerAuflistungs- und Datenkanal einbinden.
Ich hab natürlich schonmal gegoogelt, aber das hat alles nicht funktioniert.

Kleine Zusammenfassung, was ich bisher gefunden habe:

Spoiler anzeigen

Zitat von https://www.kodinerds.net/index.php/Thread/68097-FTP-mit-Auth-TLS-als-Mediasource/
Code
pathversion="1">ftp://user:pass@IP:Port?auth=tls/</path>

Zitat von https://forum.kodi.tv/showthread.php?tid=196044
HTML
ftp://USERNAME:PASSWORD@123.123.123.123:21201/|AUTH=TLS

Zitat von https://forum.libreelec.tv/thread/14005-how-to-connect-to-filezilla-ftp-over-tls-server-to-stream-music/

Code

ftps://user:password@myddns.ddns.net//Video/|Auth=SSL-TLS
ftps://user:password@myddns.ddns.net/Video/|Auth=SSL-TLS
ftps://user:password@myddns.ddns.net//Video/?pasv|Auth=SSL-TLS
ftps://user:password@myddns.ddns.net//Video/?passive|Auth=SSL-TLS
ftps://user:password@myddns.ddns.net//Video/|Auth=SSL-TLS
(...)
ftps://user:password@myddns.ddns.net:990/|auth=SSL/TLS
What I forgot to mention that when using |auth=SSL/TLS&verifypeer=false you don't need to do anything with cacert.pem on LE box. But obviously this is not good from security perspective.

Ich bin mir mit der Syntax nicht ganz sicher:

Spoiler anzeigen

- ftp:// oder ftps:// ?
- auth oder Auth oder AUTH oder ist Groß-Klein-Schreibung egal?
- =ssl oder =Ssl oder =SSL oder =SSL/TLS oder =SSL-TLS oder ...?
- |auth deor ?auth oder ?|auth oder |?auth ?
- Funktioniert verifypeer=false wirklich, um den Zertifikats-Validierungs-Check zu überspringen?
- Funktioniert pasv oder passive wirklich um eine PASV ftp connection aufzubauen (auf dem command channel oder dem file transfer channel oder beiden?)

Was ich bisher versucht habe:

Spoiler anzeigen

Code

ftps://un:pw@my.dyn.dns:51337/path/to/videos/|auth=SSL/TLS&verifypeer=false:

Ergebnis im Server-Log:

Spoiler anzeigen

Code

21/08/04 23:05:10, 3913, 1.2.3.4, , new connection from 1.2.3.4 on 192.168.178.13:51337 (Explicit SSL)
21/08/04 23:05:11, 3913, 1.2.3.4, , hostname resolved : my.wan.host.kabel-badenwuerttemberg.de
21/08/04 23:05:11, 3913, 1.2.3.4, , sending welcome message.
21/08/04 23:05:11, 3913, 1.2.3.4, , 220 Gene6 FTP Server v3.10.0 (Build 2) ready...
21/08/04 23:05:11, 3913, 1.2.3.4, , disconnected. (00d00:00:00)

Die Verbindung wird nach der welcome mesage getrennt.
Kodi zeigt folgende Fehlermeldung "Couldn't retrieve directory information. This could be due to the network not being connected. Would you like to add it anyway?".

Code

ftp://un:pw@my.dyn.dns:51337/path/to/videos/|auth=SSL/TLS&verifypeer=false

Ergebnis im Server-Log:

Spoiler anzeigen

Code

21/08/04 23:08:38, 3916, 1.2.3.4, , new connection from 1.2.3.4 on 192.168.178.13:51337 (Explicit SSL)
21/08/04 23:08:38, 3916, 1.2.3.4, , hostname resolved : my.wan.host.kabel-badenwuerttemberg.de
21/08/04 23:08:38, 3916, 1.2.3.4, , sending welcome message.
21/08/04 23:08:38, 3916, 1.2.3.4, , 220 Gene6 FTP Server v3.10.0 (Build 2) ready...
21/08/04 23:08:38, 3916, 1.2.3.4, , AUTH SSL
21/08/04 23:08:38, 3916, 1.2.3.4, , 234 AUTH command ok; starting SSL connection.
21/08/04 23:08:38, 3916, 1.2.3.4, , establishing encrypted session
21/08/04 23:08:38, 3916, 1.2.3.4, , disconnected. (00d00:00:01)

Kodi disconnected nach Aufbau der SSL-Verbindung. Passen vllt. die OpenSSL-Versionen nicht zusammen?
Kodi zeigt in diesem Fall keine Fehlermeldung, sondern einfach einen leeren Ordner an...

So sieht der Anfang einer erfolgreichen Verbindung von FTPRush v2 mit meinem Gene6-FTP-Server aus:

Spoiler anzeigen

Code

21/08/04 23:06:07, 3914, 1.2.3.4, , new connection from 1.2.3.4 on 192.168.178.13:51337 (Explicit SSL)
21/08/04 23:06:07, 3914, 1.2.3.4, , hostname resolved : my.wan.host.kabel-badenwuerttemberg.de
21/08/04 23:06:07, 3914, 1.2.3.4, , sending welcome message.
21/08/04 23:06:07, 3914, 1.2.3.4, , 220 Gene6 FTP Server v3.10.0 (Build 2) ready...
21/08/04 23:06:07, 3914, 1.2.3.4, , AUTH SSL
21/08/04 23:06:07, 3914, 1.2.3.4, , 234 AUTH command ok; starting SSL connection.
21/08/04 23:18:47, 3919, 1.2.3.4, , establishing encrypted session
21/08/04 23:18:47, 3919, 1.2.3.4, , PBSZ 0
21/08/04 23:18:47, 3919, 1.2.3.4, , 200 PBSZ=0
21/08/04 23:18:47, 3919, 1.2.3.4, , USER Rhino
(...)

Alles anzeigen

Das [definition=9,3]Kodi.[definition='1','0']log[/definition][/definition] während den beiden Verbindungs-Versuchen:

Spoiler anzeigen

Code

2021-08-04 23:04:21.328 T:2984000800 WARNING: CGUIWindowManager - HandleAction - ignoring action 107, because topmost modal dialog closing animation is running
2021-08-04 23:05:11.672 T:2984000800 WARNING: Previous line repeats 2 times.
2021-08-04 23:05:11.672 T:2984000800   ERROR: CCurlFile::FillBuffer - Failed: SSL connect error(35)
2021-08-04 23:05:11.672 T:2984000800   ERROR: CCurlFile::Open failed with code 0 for ftps://USERNAME:PASSWORD@my.dyn.dns:51337/path/to/videos/:
2021-08-04 23:05:11.672 T:2984000800   ERROR: GetDirectory - Error getting ftps://USERNAME:PASSWORD@my.dyn.dns:51337/path/to/videos/|auth=SSL/TLS&verifypeer=false
2021-08-04 23:05:19.261 T:2984000800 WARNING: CGUIWindowManager - HandleAction - ignoring action 107, because topmost modal dialog closing animation is running
2021-08-04 23:08:39.219 T:2984000800 WARNING: Previous line repeats 127 times.
2021-08-04 23:08:39.219 T:2984000800   ERROR: CCurlFile::FillBuffer - Failed: SSL peer certificate or SSH remote key was not OK(60)
2021-08-04 23:08:39.219 T:2984000800 WARNING: CGUIWindowManager - HandleAction - ignoring action 107, because topmost modal dialog closing animation is running
2021-08-04 23:09:23.058 T:2785796304 WARNING: Previous line repeats 14 times.
2021-08-04 23:09:23.059 T:2785796304   ERROR: CCurlFile::FillBuffer - Failed: SSL peer certificate or SSH remote key was not OK(60)
2021-08-04 23:09:55.222 T:2785796304   ERROR: CCurlFile::FillBuffer - Failed: Timeout was reached(28)
2021-08-04 23:09:55.222 T:2785796304   ERROR: CCurlFile::Open failed with code 0 for ftp://USERNAME:PASSWORD@192.168.178.13:51337/path/to/videos/:
2021-08-04 23:09:55.223 T:2785796304   ERROR: GetDirectory - Error getting ftp://USERNAME:PASSWORD@192.168.178.13:51337/path/to/videos/
2021-08-04 23:09:55.242 T:2984000800   ERROR: CGUIMediaWindow::GetDirectory(ftp://USERNAME:PASSWORD@192.168.178.13:51337/path/to/videos/) failed
2021-08-04 23:15:39.109 T:2984000800   ERROR: CCurlFile::FillBuffer - Failed: SSL connect error(35)
2021-08-04 23:15:39.109 T:2984000800   ERROR: CCurlFile::Open failed with code 0 for ftps://USERNAME:PASSWORD@my.dyn.dns:51337/path/to/videos/:
2021-08-04 23:15:39.109 T:2984000800   ERROR: GetDirectory - Error getting ftps://USERNAME:PASSWORD@my.dyn.dns:51337/path/to/videos/|auth=SSL/TLS&verifypeer=false

Alles anzeigen

Mir stechen die Zeilen
CCurlFile::FillBuffer - Failed: SSL connect error(35)

CCurlFile::FillBuffer - Failed: SSL peer certificate or SSH remote key was not OK(60)
ins Auge.
Ich verwende ganz bewusst ein ungültiges Zertifikat, um die Verbindung überhaupt verschlüsseln zu können. Den Check würde ich gerne überspringen, was ich erhofft habe über verifypeer=false zu erreichen.

Setup-Infos:

Spoiler anzeigen

Kodi 18.9.0 auf XBian 1.0 auf einem Raspberry Pi 4 (B?)
Gene6 FTP Server 3.10.0.2 mit OpenSSL 1.0.2h

Kann mir jemand helfen, das zum Laufen zu bekommen?

Vielen Dank schonmal und viele Grüße,
Rhino

darkside40

Ist wahrscheinlich nicht was du hören willst, aber FTP ist ein Protokoll was langsam von der Bildfläche verschwindet.
Aus den meisten Browsern ist es schon raus geflogen.

Des weiteren benutzt du einen uralten FTP Server inkl. OpenSSL Version von 2016.
Es ist wahrscheinlich das in dieser Software genug Bugs enthalten sind, das du dir um den Einsatz von SSL garkeinen Kopf machen musst.

Es ist zig mal einfacher einen nginx + WebDAV Extension + Lets Encrypt zum laufen zu bekommen. Die Software ist wenigstens aktiv supported.

Rhino Cracker

Habs, son Profi im IRC hat mir geholfen: Mit cURL versucht zu connecten und gesehen, dass mein Zertifikat Müll ist.
Hab ein neues erstellt - anscheinend müssen zumindest der "Common Name" im Zertifikat und die SubDomain.SecondLevelDomain.TopLevelDomain gleich sein, damit cURL den Dienst nicht verweigert, auch bei verifypeer=false.

(zu deutsch: wenn man sich deinemudda.dyndns.org als dyndns einrichtet und versucht zu ftp://deinemudda.dyndns.org:1337/ zu connecten, muss das Zertifikat im CommonName deinemudda.dyndns.org drin stehen haben.)

Eingetragen habe ich jetzt ftp:// (also ohne s).
Bei dem Zeug hinter | (also auth=TLS) macht Groß- und Kleinschreibung keinen Unterschied, das wird laut Kodi-Quelltext ToLowerCase transformiert.

Um mein völliges Müll-Zertifikat zu akzeptieren, müsste Kodi vermutlich die Option https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html zu cURL durchschleifen. Es schleift aber nur https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html über verifypeer=false durch.

Verbleibende Probleme: 1. Rar-File-Read funktioniert hier nicht, während es bei unverschlüsselten Lan-FTPs und SMB funktioniert hat.
2. Ich kann keinen enthaltenen Medientyp auswählen.

Rhino Cracker

Zitat von Rhino Cracker

Verbleibende Probleme: 1. Rar-File-Read funktioniert hier nicht, während es bei unverschlüsselten Lan-FTPs und SMB funktioniert hat.

Dazu habe ich herausgefunden, dass Kodi die Information "vergisst", dass es per SSL auf den FTP zugreifen soll, während es versucht, die Rar-Teilarchive anzuladen: .rar-Zugriff erfolgt per SSL, .r00, .r01, ... versucht er dann über eine neue Verbindung ohne SSL, die vom Server abgewiesen wird (SSL only allowed).

WansHurst

Neue Erkenntnisse?

FTP läuft bei mir mit verifypeer=false wunderbar, aber letztlich ist die Verbindung auch nicht sicher. Hatte gestern im Sourcecode von Kodi gestöbert. Soweit ich es beim überfliegen erkennen konnte, liegt das Problem bei CURL bzw. der Zertifikatsvalidation. Leider sind meine c++ Skills auch nicht die besten und es ist schon 15 Jahe lange her als ich damals damit herumgespielt habe. Gibts hier jemanden der Zeit und Bock hat das Problem mit mir im Quellcode von Kodi zu beheben?

Zitat von Rhino Cracker

Um mein völliges Müll-Zertifikat zu akzeptieren, müsste Kodi vermutlich die Option https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html zu cURL durchschleifen. Es schleift aber nur https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYPEER.html über verifypeer=false durch.

"NSS: If CURLOPT_SSL_VERIFYPEER is zero, CURLOPT_SSL_VERIFYHOST is also set to zero and cannot be overridden."

Quelle: https://curl.se/libcurl/c/CURLOPT_SSL_VERIFYHOST.html

darkside40

Wie wäre es einfach auf ein vernünftiges Protokoll zu setzen.
Zum Beispiel HTTP + TLS inform eines nginx Reverse Proxy oder SFTP (SSH File Transfer Protokoll), anstatt sich mit FTP und angeflanschtem SSL rumzuschlagen?

WansHurst

Zitat von darkside40

Wie wäre es einfach auf ein vernünftiges Protokoll zu setzen.
Zum Beispiel HTTP + TLS inform eines nginx Reverse Proxy oder SFTP (SSH File Transfer Protokoll), anstatt sich mit FTP und angeflanschtem SSL rumzuschlagen?

Weil ich nur eine Fritzbox habe und ich somit nicht die Möglichkeit für Ihre Vorschläge habe. Ganz abzusehen davon, dass Kodi ein Protokoll unterstützt aber es nicht vollständig funktioniert. Entweder man dropped das Feature, wenn man keinen Wert drauf legt, oder man berichtigt die Fehler. Dieses Phänomen existiert bereits seit vielen Jahren und ich finde es ehrlich gesagt ein Unding. Nun versuche ich das Problem selber anzugehen. Ganz gleich was Sie oder ein Anderer vom FTP Protokoll halten mag, die Community wird sich sicher freuen, wenn der Fehler nach vielen Jahren behoben ist, natürlich, sofern es mir gelingt. Rumschlagen? Ich sehe es als ein kleinen Beitrag für die Kodi Community und in diesem Kontext nicht als Ärgernis.

darkside40

Dann hoffe ich das du den Fehler beheben kannst in einem Protokoll welches so gut wie niemand mehr (aus guten Gründen) benutzt.

Es ist nicht umsonst inzwischen aus allen großen Browsern rausgeflogen, und die Tatsache das dieses Problem seit ca. 2019 ungelöst ist zeigt wohl auch wie hoch das im Team Kodi aufgehängt ist.

Ein feature zu droppen nur weil ein Teil davon nicht funktioniert ist eine blöde Idee, das könnte auch andere Betreffen die dieses Subfeature nicht nutzen. Aber wie gesagt ich wünsch dir Glück.

Hast du vielleicht schonmal mit einem hinterlegten Lets Encrypt Cert in der Fritzbox versucht?

Vielleicht hat @DaVu ja noch einen Gedanken dazu.

DaVu

Zitat von WansHurst

Dieses Phänomen existiert bereits seit vielen Jahren und ich finde es ehrlich gesagt ein Unding

PR Welcome

Ich habe mich mit Kodi und Zertifikaten noch nie auseinander gesetzt. Meine Quellen sind alle lokal in meinem heimischen LAN. Da brauche ich keine Zertifikate.

Rhino Cracker

Zitat von WansHurst

Neue Erkenntnisse?

Nicht wirklich. Ich hab mich nicht weiter damit beschäftigt. Meine derzeitige Arbeit frisst meinen ganzen Bastler-Elan auf

Zitat von WansHurst

Soweit ich es beim überfliegen erkennen konnte, liegt das Problem bei CURL bzw. der Zertifikatsvalidation.

Das mit dem Zert habe ich ja soweit umgangen: Ein neues Zertifikat mit passendem CN angelegt:

EDIT: Das Forum macht hier komisches Zeug mit meinem Bild, hier deshalb ein Link dazu: https://i.postimg.cc/1zGnNSW-K/image.png

Externer Inhalt i.postimg.cc

Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.

Mir wäre es zwar lieber, ich könnte Kodi/cURL sagen, es soll in dem Fall ein unsinniges Zert akzeptieren, aber VerivyHost ist halt nicht setzbar.

Problem jetzt: Er lädt die .rar über SSL, aber die anderen Teilarchive dann ohne SSL. Da vergisst er quasi den Zusatz "benutze SSL" (und wird erstmal von meinem Server abgewiesen, da der nur SSL erlaubt)

Zitat von DaVu

Ich habe mich mit Kodi und Zertifikaten noch nie auseinander gesetzt. Meine Quellen sind alle lokal in meinem heimischen LAN. Da brauche ich keine Zertifikate.

Ohne Zertifikat gibts halt keine Verschlüsselung. Ansonsten hätte ich auch keins

Ich denke, am jetzigen Punkt würde sich das am Besten jemand anschauen, der sich mit der gesamten Kodi-Software (und deren Source-Code) besser auskennt als ich.
Beim Iterieren über die Teilarchive, Irgendwo zwischen dem Saugen der Hauptdatei (*.rar) und dem darauffolgenden Ansaugen der anderen Teile (*.r01, *.r02, ...), "vergisst" Kodi die Anweisung, auch die Teilarchive mit SSL zu laden.
Ich müsste jetzt die gesamte Befehlskette suchen, verstehen, debuggen (und mir davor erstmal eine Debugging-Umgebung für Kodi aufbauen).
jemand der da drin ist, kann vermutlich direkt beim Iterator ansetzen und schauen, wo das |Auth=TLS verschwindet und wie man das mit schleift (String-Replacement anpassen, zusätzlichen Parameter mitgeben, etc., etc., etc.).

Also so erkläre ich es mir im Moment. Ich kann auch komplett auf dem Holzweg sein.

Achso, ganz vergessen, ich hatte hier ein Ticket angelegt: https://github.com/xbmc/vfs.rar/issues/119
forgets ssl for splitted archives in ftp sources with auth ssl/tls #119

darkside40

Wieso behilfst du dir nicht damit einfach nur eine Datei statt gesplitteten Archiven zu verwenden.
Filmdateien in Archive zu packen macht eh keinen Sinn da nicht komprimierbar.

Das setzt man doch eh nur in der Warez Szene ein.

Rhino Cracker

Es gibt viele Wege um Rom

Ich will jetzt halt nicht mein gesamtes Archiv umbauen, für Kodi.
Und auch nicht auf einer Maschine, die ich soweit ich nur konnte entschlackt habe, die kaum Leistung hat und die seit 10 Jahren quasi so eingefroren läuft, so wie sie ist, jetzt zig Protokoll-Server aufsetzen, nur damit ich das Zeug in Kodi rein kriege.

Wege drum herum gibt es ja etliche:
- nfs-server aufsetzen
- über ssh gehts wohl irgendwie
- curlftpfs aufm Pi (hat schon einer ausprobiert, hat Nachteile wenn Kodi denkt das Zeug wäre lokal)
- nginx wie du meintest (hör ich zum ersten mal)
- WebDav und was weiß ich alles
- Server hier her stellen

Ich würde aber gerne den gehen mit dem Zeug, das ich schon habe.

Dass FTP aus den Browsern rausgeflogen ist, hat übrigens dazu geführt, dass wir auf der Arbeit wieder mit dem InternetExplorer arbeiten müssen, um z.B. Lizenztexte herunter zu laden, die halt noch auf FTPs liegen. Das nennt sich dann technischer Fortschritt

Grund für den Trend war (soweit ich weiß), dass FTP meist eben ohne Verschlüsselung und Zertifikat abläuft und deshalb Man-In-The-Middle-Attacken nicht verhindert. Die meisten Browser können (konnten) dann FTPS/SFTP gar nicht und die meisten Webseitenbetreiber stellen ihren FTP-Server auch nicht dafür ein (wenn er es überhaupt kann).

Das hat dann auch dazu geführt, dass ich im Moment keinen Weg mehr habe, um mit Freunden mit 3 Klicks Dateien zu teilen (war bisher Rechtsklick, make available through ftp.bat (2. Klick), Strg+A Strg+C (im aufgehenden Textfenster), Nachrichtenfenster auf (3. Klick), Strg+V, Enter), ohne ihnen gleich einen FTP-Client anzudrehen und erklären zu müssen, sondern wieder Drittanbieter brauche...

Ich sehs jedenfalls als seit Jahrzehnten bewährtes Protokoll, das seit Ewigkeiten auch Verschlüsselung unterstützt. Warum also auf etwas Neues setzen, wenn das Alte doch so gut funktioniert?

Jetzt mitmachen!