vsftpd - Fehlerhafte Dateiübertragung mit TLSv1.3 & AES128

[Drystanz]

Hallo zusammen,

ich habe ein Problem mit vsftpd und TLSv1.3, das sowohl vsftpd-3.0.3 als auch vsftpd-3.0.5 betrifft. Ich kann problemlos mit gFTP und lftp eine Verbindung über TLSv1.3 mit TLS_AES_256_GCM_SHA384 herstellen und Dateien übertragen. Das Gleiche gilt auch für TLSv1.2 mit ECDHE-RSA-AES256-GCM-SHA384.

Allerdings besteht das Problem, dass meine Android-Smartphones bzw. Apps die Verbindung (wenn auf TLSv1.3 konfiguriert ist) nur mit TLS_AES_128_GCM_SHA256 aufbauen. Obwohl sie sich erfolgreich am Server anmelden können, ist es nicht möglich, Dateien vollständig zu übertragen. Insbesondere werden Bilder nur teilweise übertragen, sodass nur Teile des Bildes sichtbar sind.

Dieses Problem betrifft alle getesteten Android FTP-Clients, und ich habe es sowohl mit einem Samsung M52 (Android 13) als auch mit einem Xiaomi 9T Pro (LineageOS 20) getestet. Der Server läuft auf Debian Bookworm.

Weiß jemand, wo genau das Problem liegt?

 

[Luftgucker]

Ich tipp mal auf fehlerhaften RAM beim Server.

 

[klausk1978]

@Luftgucker
So einen Schwachsinn habe ich noch nie gelesen. Kannst du deine 'Vermutung' auch begründen?

Ergänzung (8. Dezember 2023)

Es scheint, dass das Problem mit der Übertragung von Dateien über vsftpd und TLSv1.3 auf Android-Geräten auftritt, insbesondere wenn die Verschlüsselung auf TLS_AES_128_GCM_SHA256 festgelegt ist. Es ist möglich, dass die Implementierung von TLS in diesen Android-Apps möglicherweise nicht vollständig kompatibel ist oder es sich um eine Konfiguration handelt, die auf bestimmten Android-Versionen oder -Geräten nicht richtig funktioniert.

Hier sind einige mögliche Ansätze, um das Problem zu untersuchen und zu lösen:

Protokollierung aktivieren: Aktiviere ausführliche Protokolle auf dem vsftpd-Server, um mehr Einblicke in die Verbindung und Fehlermeldungen zu erhalten. Überprüfe die vsftpd-Protokolle, um festzustellen, ob Fehler oder Warnungen auftreten, wenn Verbindungen von Android-Geräten versuchen, Dateien zu übertragen.

Analyse der Verschlüsselungseinstellungen: Überprüfe die vsftpd-Konfiguration, um sicherzustellen, dass die TLS-Einstellungen korrekt konfiguriert sind und keine Einschränkungen für Android-Geräte bestehen. Möglicherweise kannst du verschiedene Verschlüsselungssuiten oder Konfigurationsoptionen testen, um zu sehen, ob eine andere Konfiguration besser funktioniert.

Es ist möglich, dass die Einschränkung auf TLS_AES_128_GCM_SHA256 auf den Android-Geräten oder in den Apps liegt, die möglicherweise nicht optimal mit vsftpd und dieser speziellen Verschlüsselungssuite funktionieren. Das Experimentieren mit verschiedenen Konfigurationen und die Kommunikation mit Entwicklern können hierbei hilfreich sein.

 

[till69]

fehlerhaften RAM beim Server

🤦‍♂ Ja, ganz bestimmt:

Ich kann problemlos mit gFTP und lftp eine Verbindung über TLSv1.3 mit TLS_AES_256_GCM_SHA384 herstellen und Dateien übertragen

 

[0x8100]

ich weiss, dass es nicht zum eigentlichen problem beiträgt, aber warum noch ftp(s) und nicht einfach sftp?

 

[Drystanz]

Es ist möglich, dass die Einschränkung auf TLS_AES_128_GCM_SHA256 auf den Android-Geräten oder in den Apps liegt, die möglicherweise nicht optimal mit vsftpd und dieser speziellen Verschlüsselungssuite funktionieren. Das Experimentieren mit verschiedenen Konfigurationen und die Kommunikation mit Entwicklern können hierbei hilfreich sein.

Das Problem ist mir vor acht Wochen zum ersten Mal aufgefallen. Nachdem ich vsftpd-3.0.5 übersetzt hatte und das Problem weiterhin bestand, habe ich die Logs untersucht. Erst da ist mir aufgefallen, dass keine Android-FTP-App oder Explorer Dateien mit AES256 überträgt, sondern nur mit AES128. Gibt es überhaupt eine Android-FTP-App, die TLSv1.3 und AES256 unterstützt ? Nur um es einmal zu testen und zu überprüfen, ob das die Ursache ist.

Ergänzung (8. Dezember 2023)

ich weiss, dass es nicht zum eigentlichen problem beiträgt, aber warum noch ftp(s) und nicht einfach sftp?

Anfangs lief es mit SMB. Allerdings, bei großen Dateien und mehreren Benutzern, war der RAM schnell erschöpft, und das Ganze war langsamer als es jetzt mit FTP der Fall ist. Das war der Grund, warum wir vor 2-3 Jahren auf vsftpd umgestiegen sind.

 

[0x8100]

Anfangs lief es mit SMB.

ich bin inzwischen auch komplett von smb weg, allerdings läuft jetzt alles über ssh/sftp. gibt genügend android file-manager, die das können und selbst in windows kann man es direkt mounten. unter linux geht es natürlich direkt mit sshfs. nur so als anregung, vielleicht kommst du damit ja von ftp weg - ssh hast du ja sowieso schon am laufen, wäre dann ein (nerviges) protokoll weniger

 

[Drystanz]

Mit TLSv1.2 funktioniert ja alles. Bis zu 20 Rechner und Smartphones können problemlos und gleichzeitig auf den Server zugreifen bzw. auf ihre privaten Clouds zugreifen oder Daten sichern. FTP-Clients sind sehr einfach einzurichten. Das Problem ist TLSv1.3. Man muss es noch nicht haben, aber irgendwie will ich es doch schon sauber am laufen haben.

 

[Mojo1987]

Das Problem wird sein das es im Server oder den Clients vermutlich nicht sauber implementiert ist. Hatte das Problem mit etwas nieschigeren Windows FTP Clients auch schon. Ich wage zu bezweifeln das die FTP Clients für Android da besser gepflegt sind.

Möglich wäre auch das Smartphones das wegen der nötigen Rechenleistung ggf. bisher nicht unterstützen.

Ich würde dem ganzen noch etwas Zeit zum reifen geben.

 

[Drystanz]

TLSv1.3 wird auf jeden Fall nicht für jedermann aktiviert, sondern nur für mich, um es weiter zu testen. Im Netz ist kaum etwas über Android und FTP mit TLSv1.3 zu finden. Ich bin wohl der einzige weltweit, der sich darüber Gedanken macht . Vorhin stieß ich auf einen User, der die Sache echt schwarz siieht und meint, dass eine saubere Implementierung selbst in den nächsten 10 Jahren nichts wird.

 

[Uridium]

Das sind nur Spekulationen und die Symptome sprechen auch nicht dafür. Schau dir die Logs an. Dafür sind sie da.

 

[Drystanz]

Die Log-Datei sagt echt nicht viel. Wenn ich Dateien zum Server hochlade, kriege ich diese Standardfehlermeldungen (426 Failure reading network stream bzw. SSL error: error:00000000:lib(0)::reason(0), errno: 32). Das passiert aber nur bei Android FTP-Clients (mit AES128). Der Transfer geht nur bis 16 KB, dann ist Schluss. Was ich nicht verstehe ist, es betrifft nur den Upload, und das nur bei TLSv1.3/AES128. Mit TLSv1.2 AES256 gibt es keine Probleme. Was ich noch weniger verstehe: Warum können gFTP und lftp problemlos mit TLSv1.3 Dateien herunter- und hochladen, während die Konfiguration dieselbe ist ? Der einzige Unterschied ist, dass die Linux-Anwendungen gFTP und lftp AES256 nutzen, während die Android-Apps AES128 verwenden.

FTPS Upload does not work on vsftpd 3.0.3

Ergänzung (9. Dezember 2023)

Möglich wäre auch das Smartphones das wegen der nötigen Rechenleistung ggf. bisher nicht unterstützen.

Smartphones sind heute recht leistungsstark. Ein Qualcomm SD855 hat sicherlich mehr Leistung als mein altes Notebook mit Ivy Bridge. Abgesehen davon habe ich in den letzten Tagen Dutzende von Android FTP-Clients ausprobiert, und alle konnten nur bis AES128. Ich frage mich bezogen auf AES256 ..

• Geht es nicht
• können sie es nicht
• dürfen sie es nicht ?
• liegt es vielleicht an Android ?

 

[Mojo1987]

Deine Ivy Bridge hat aber AES-NI als Instruktion Set und tut sich daher um Welten einfacher sowas abzuarbeiten. Keine Ahnung wie das mit dieser Art Instruktion Set bei Mobile CPUs aussieht. Es ist schon auffällig das es scheinbar kein Android Client kann.

 

[klausk1978]

@Drystanz

Probiere die Lösung im folgenden Link mal aus.
(in /etc/vsftpd.conf: strict_ssl_read_eof=NO)

Link dazu: https://www.suse.com/de-de/support/kb/doc/?id=000020678

 

[Drystanz]

Das ist nur eine Option, damit kein Angreifer mit 'nem gefakten TCP-FIN deinen Upload vorzeitig abwürgt.

Das Problem sehe ich anderswo. Ich vermute mal stark, dass es am SSL-shutdown liegt. Also, wie die SSL-Verbindung beendet wird. Normalerweise wird eine SSL-Verbindung durch Senden und Empfangen von bestimmten Steuerbefehlen beendet. Der Entwickler von Mixplorer meint, dass es an vsftpd liegt. Ehrlich gesagt weiß ich es (noch) nicht.

Ergänzung (9. Dezember 2023)

Deine Ivy Bridge hat aber AES-NI als Instruktion Set und tut sich daher um Welten einfacher sowas abzuarbeiten. Keine Ahnung wie das mit dieser Art Instruktion Set bei Mobile CPUs aussieht. Es ist schon auffällig das es scheinbar kein Android Client kann.

Ich denke nicht, dass es daran liegt. Liegt es nicht an der FTP-App, die die Verbindung aufbaut ? Schlie?lich möchte ich ja keine Dateien mit AES256 verschlüsseln. Wenn die App die Funktion implementiert hat, wird man die AES-NI Funktion nicht brauchen, denke ich mal das es so ist.

 

[Y-Chromosome]

Erlaubst Du TLS_CHACHA20_POLY1305_SHA256?
Das ist der präferierte Cipher für Android, bzw. für mobile Geräte.

 

[Pummeluff]

Der Entwickler von Mixplorer meint, dass es an vsftpd liegt.

Etwas OT: Ich hatte vor einigen Jahren mal ein System von SLES11 auf RHEL7 umgestellt. Als FTP-Server lief bis dahin PureFTPd. Die Empfehlung von Redhat war vsFTPd. Am anderen Ende lieferten uralte DEC-Alpha-Stationen die Daten. Die Verbindung wurde über passives FTP aufgebaut. Der Server schickt dabei dem Client kodiert den Port, auf den er dann die Datenübertragung erwartet. Das klappte mit vsFTPd nicht. Irgendwas war da auch falsch kodiert. Ich bin damals zurück auf PureFTPd.

Lange Rede kurzer Sinn:
Probier mal einen anderen FTP-Server aus: PureFTPd oder ProFTPd.

 

[Uridium]

Ich würde nach den Logs den Datenstrom (tcpdump/wireshark) analysieren und auf fragmentierte/fehlerhafte Pakete untersuchen. Die Handys auch lokal im Lan testen. Das ganze 6to4/MTU/Netzwechsel Gebimsel wird vielleicht nicht immer ordnungsgemäß umgesetzt. Auch im Heimbereich. Ich könnte mir vorstellen, dass die Pakete (unnötig) fragmentiert werden müssen und TLS das nicht zulässt. Klassischer Netzwerkkonfigurationsfehler.

 

[Drystanz]

Erlaubst Du TLS_CHACHA20_POLY1305_SHA256?
Das ist der präferierte Cipher für Android, bzw. für mobile Geräte.

Mit TLSv1.2 kann ich es entsprechend konfigurieren bzw. auswählen, aber mit TLSv1.3 funktioniert es irgendwie nicht. Die Konfiguration wird ignoriert.

Ergänzung (9. Dezember 2023)

Ich würde nach den Logs den Datenstrom (tcpdump/wireshark) analysieren und auf fragmentierte/fehlerhafte Pakete untersuchen. Die Handys auch lokal im Lan testen. Das ganze 6to4/MTU/Netzwechsel Gebimsel wird vielleicht nicht immer ordnungsgemäß umgesetzt. Auch im Heimbereich. Ich könnte mir vorstellen, dass die Pakete (unnötig) fragmentiert werden müssen und TLS das nicht zulässt. Klassischer Netzwerkkonfigurationsfehler.

Und werden die Pakete mit TLSv1.2 nicht unnötig fragmentiert ? Das musst du mir mal erklären.

Ergänzung (9. Dezember 2023)

Etwas OT: Ich hatte vor einigen Jahren mal ein System von SLES11 auf RHEL7 umgestellt. Als FTP-Server lief bis dahin PureFTPd. Die Empfehlung von Redhat war vsFTPd. Am anderen Ende lieferten uralte DEC-Alpha-Stationen die Daten. Die Verbindung wurde über passives FTP aufgebaut. Der Server schickt dabei dem Client kodiert den Port, auf den er dann die Datenübertragung erwartet. Das klappte mit vsFTPd nicht. Irgendwas war da auch falsch kodiert. Ich bin damals zurück auf PureFTPd.

Lange Rede kurzer Sinn:
Probier mal einen anderen FTP-Server aus: PureFTPd oder ProFTPd.

Ich werde mich noch ein wenig mit vsftpd beschäftigen, aber ich werde mir auch ProFTPd und PureFTPd anschauen. Außerdem möchte ich mich noch ein wenig mit OpenSSL befassen. Es zeigt mir entsprechende Chiffren an, die ich mit vsftpd nicht auswählen kann.

 

[Uridium]

Und werden die Pakete mit TLSv1.2 nicht unnötig fragmentiert ?

Die Frage ignoriert das dir bereits genannte Werkzeug zur Beantwortung dieser Frage. Wir sind keine Hellseher.