FTPs: Problem beim etablieren der FTP Datenverbindung

[seh]

Hallo,

ich arbeite für einen Printserver Hersteller. Unsere Produkte (Embedded Devices!) können - unter anderem - auch per FTPs angesprochen werden, was wir mit diversen FTPs Clients (z.B. Core FTP LE, GoFTP, FireFTP, LFTP, SmartFTP, ... ) für alle möglichen Betriebsarten(Implicit/Explicit/Active/Passiv) positiv erprobt haben.

Nun berichten uns Kunden, dass es mit dem TC 7.x leider nicht funktioniert. Aus Sicht eines Anwenders ist es so, dass die Verbindung beim LIST hängen bleibt bzw. nur ein leeres Verzeichnis angezeigt wird. Hier mal ein exemplarisches LOG dazu:

Code: Select all

Connect to: (15.08.2008 13:52:05)
hostname=192.168.3.105
username=anonymous
startdir=
220 SEH FTP server (InterCon version 10.2.253) ready.
AUTH TLS
234 AUTH command successful.
Cert subject: /C=DE/ST=NRW/L=Bielefeld/O=SEH/OU=Printserver IV/CN=IC0A3C6C/emailAddress=support@seh.de
Cert issuer: /C=DE/ST=NRW/L=Bielefeld/O=SEH/OU=Printserver IV/CN=IC0A3C6C/emailAddress=support@seh.de
USER anonymous
230 User anonymous logged in.
SYST
215 UNIX Type: L8
FEAT
211-Features:
 AUTH TLS
 EPRT
 EPSV
 PBSZ
 PROT
211 End
PBSZ 0
200 PBSZ 0 successful.
PROT P
200 PROT command successful.
Connect ok!
PWD
257 "/" is current directory.
Verzeichnis einlesen
TYPE A
200 Type set to A.
PASV
227 Entering passive mode (192,168,3,105,14,241).
LIST

Wir haben uns die Sache in einem Netzwerk-Trace etwas genauer angeschaut. Hier konnten wir feststellen, dass auf der Control Connection alles O.K ist. Die Kommunikation auf diesem Kanal wird ohne Probleme aufgebaut. Erst beim Aufbau der DATA Connection kommt es zu einem Problem, derweil der Total Commander (aus unserer Sicht) ein CLIENT HELLO vermissen läßt. Dummerweise konnten wir aber in einem Referenz-Test zu einem anderem FTPS Server nachvollziehen, dass der Total Commander dieses CLIENT HELLO durchaus beim Aufbau der Datenverbindung absetzt.

Wir fragen uns nun, was Ihn in unserem Fall daran hindert, ein CLIENT HELLO beim Aufbau der Datenverbindung abzusetzen? Irgendeine Idee was der Grund hierfür sein könnte?

MfG,
SEH

[norfie²]

Dumme Frage: (Software- oder Hardware-)Firewalls sind keine dazwischengeschaltet?

[seh]

Nein, definitiv nicht. Auch die im Forum nachvollziehbaren Router Probleme scheiden aus.

[Helge01]

Es liegt daran das der FTP Server die interne IP Adresse statt der externen übermittelt. Damit bleibt der TC im List 'hängen'. Andere Programme wie z.B. FileZilla unterstützen Routing und funktionieren deshalb trotzdem.

Ich sehe gerade, das es ein Zugriff innerhalb eines Netzwerkes ist, da ist die Ausage von mir falsch...

Gruß Helge

[ghisler(Author)]

Vielleicht unterstuetzt das Gerät keine verschlüsselte Datenverbindung (PROT P)? Die meisten anderen FTP-Clients übertragen die Daten unverschlüsselt.

Zum Testen bitte im Feld "Befehle senden" den Befehl
PROT C
eintragen, dann wird unverschlüsselt übertragen.

[seh]

Der Server unterstützt definitiv eine verschlüsselte Übertragung FTPs Explicit (Passiv/Activ) über Port 21 und FTPs Implicit über Port 990 sind anhand diverser Tests mit diversen anderen FTPs Clients belegt.

Die Option mit PROT C haben wir ausprobiert - und funktioniert; ist allerdings keine Alternative für uns, da wir damit ja einen verschlüsselten Steuerkanal aber einen unverschlüsselten Daten-Kanal erhalten. Wäre wie "ein bischen schwanger" und damit unbefriedigen

Vielleicht habe ich mich etwas unklar ausgedrückt:

Das initiale Aushandeln der Verschlüsselung und die Kommunikation für den Steuerkanal über Port 21 funktioniert tadellos!

Wir haben das Problem, das der darauf folgende Aufbau des FTP Datenkanals nicht funktioniert, weil der Total Commander - zumindest mit unserem Server - kein TLS Client Hello macht, sprich das Aushandeln der Verschlüsselung für den Datenkanal nicht klappt. Zumindest ist das die Situation, wie wir es in diversen Traces gesehen haben.

Wir fragen uns nun, was den Commander glauben macht, dass er mit uns das TLS Client Hello für den FTP Datenkanal nicht machen muß

[ghisler(Author)]

Total Commander baut beim Pasivmodus die Datenverbindung erst normal mit socket() und connect() auf, und ruft dann direkt die SSL-Funktionen der OpenSSL-DLL auf:

Code: Select all

    if fuse_tls then
      fdatactx:=SSL_CTX_new(TLSv1_client_method)
    else
      fdatactx:=SSL_CTX_new(SSLv23_client_method);
    err:=-1;
    if fdatactx<>nil then begin
      fdatassl:=SSL_new(fdatactx);
      if fdatassl<>nil then begin
        SSL_set_fd(fdatassl, datasock);
        err:=SSL_connect(fdatassl);
      end;
    end;

fuse_tls ist TRUE, wenn bei der Befehlsverbindung auf AUTH TLS mit 2xx oder 3xx geantwortet wurde, was ja nach obigem Log der Fall ist. Der Verbindungaufbau sieht damit fast gleich aus wie bei der Befehlsverbindung:

Code: Select all

    ssl_clear_errors;
    if fuse_tls then
      fctrlctx:=SSL_CTX_new(TLSv1_client_method)
    else
      fctrlctx:=SSL_CTX_new(SSLv23_client_method);
    err:=-1;
    if fctrlctx<>nil then begin
      if fileexists(rootcertsfile) then begin
        SSL_CTX_set_verify(fctrlctx,SSL_VERIFY_PEER,@ssl_verify_callback);
        SSL_CTX_set_verify_depth(fctrlctx,20);
        SSL_CTX_set_default_verify_paths(fctrlctx);
        SSL_CTX_load_verify_locations(fctrlctx,rootcertsfile,nil);
      end;
      fctrlssl:=SSL_new(fctrlctx);
      if fctrlssl<>nil then begin
        SSL_set_fd(fctrlssl, fCtrlSock);
        err:=SSL_connect(fctrlssl);

Vieleicht mag Ihr Server ja die Reihenfolge nicht, in der Total Commander vorgeht:
1. PASV-Befehl senden
2. Auf Antwort mit der Verbindungs-IP warten
3. Zu dieser IP verbinden, aber noch nichts senden
4. LIST-Befehl senden
5. SSL-Negotiation und Daten übertragen

[Hacker]

seh,

Wir haben uns die Sache in einem Netzwerk-Trace etwas genauer angeschaut.

Wo wurde denn dieser gemacht? Beim Klienten oder beim Server?

was wir mit diversen FTPs Clients (z.B. Core FTP LE, GoFTP, FireFTP, LFTP, SmartFTP, ... ) für alle möglichen Betriebsarten(Implicit/Explicit/Active/Passiv) positiv erprobt haben

Unterscheidet sich ein Capture beim benutzen dieser von einem Capture beim benutzen des TC?

Roman

[seh]

Tatsächlich wurden mehrere Captures des TC gefahren. Bei komplexen Umgebungen tracen wir in aller Regel direkt an unserem Server/Produkt, derweil wir erstmal den Ereignishorizont unseres eigenen Systems ermitteln müssen. In diesem konkreten Fall haben wir in einem Testnetz mit einer extrem flachen Hierarchie getraced, wobei der Trace auf dem System lief, das auch den Total Commander hatte.

Wir haben im Sachzusammenhang nicht alle genannten FTPs Clients nochmal mitgeschnitten, sondern nur eine Auswahl. Als signifikanter Unterschied wurden das ausbleiben des TLS Client Hello festgestellt. Darüber hinaus haben wir in erster Näherung nichts festgestellt. Ich denke aber wir sind gut beraten der Empfehlung von ghisler zu folgen und noch mal einen kritischen Blick auf die Timings zu werfen.

[seh]

Vieleicht mag Ihr Server ja die Reihenfolge nicht, in der Total Commander vorgeht:
1. PASV-Befehl senden
2. Auf Antwort mit der Verbindungs-IP warten
3. Zu dieser IP verbinden, aber noch nichts senden
4. LIST-Befehl senden
5. SSL-Negotiation und Daten übertragen

Die Reihenfolge ist genau wie wir sie erwarten.

Die Punkte 1. - 4. werden ja auch sauber abgearbeitet. Bei 5. tritt der besagte Fehler auf, den wir uns nicht erklären können.

Im Trace ist es so, daß der 3-Wege Handshake für die TCP Connection zum FTP Datachannel sauber abgearbeitet wird. Danach erwarten wir das der TC ein TLS/SSL Handshake (Client Hello) einleitet.

Auf unserer Seite wird dazu, nachdem die TCP-Connection zum FTP-Datachannel etabliert ist und unser Server das LIST-Kommando empfangen hat, in etwa der folgender Code ausgeführt:

Code: Select all

    fdatactx:=SSL_CTX_new(SSLv23_server_method);
    if fdatactx<>nil then begin
      fdatassl:=SSL_new(fdatactx);
      if fdatassl<>nil then begin
        SSL_set_fd(fdatassl, datasock);
        SSL_accept(fdatassl);
      end;
    end;

Wir bekommen aber kein TLS/SSL Client Hello, stattdessen beendet der TC nach ziemlich exakt 10s die TCP Verbindung mit einem FIN.

Frage 1) Läßt sich im Commander überprüfen unter welchen Bedingungen das "10s Timeout" ausgelößt wird?

Wir haben in den Traces mal die Laufzeiten der TCP Pakete und somit die Anwortzeiten verglichen: Im Fehlerfall (getestet mit dem tC und einem unsere Produkte) wird der 3-Wege-Handshake extrem schnell abgewickelt. Im "Gut-Fall" (getestet mit dem TC und dem FTPS Server von SMARTFTP) sind die Paket Antwort/Laufzeiten wesentlich größer.

Frage 2) Kann es sein, dass sehr kleine Antwortzeiten dazu führen das es auf Seiten des Commanders zu Problemen kommt?

SEH

[ghisler(Author)]

fdatactx:=SSL_CTX_new(SSLv23_server_method);

Hmm, vielleicht liegt es daran? TC erwartet ein TLS-Handshake, Sie machen aber eine SSLv2/3-Handshake?

Frage 1) Läßt sich im Commander überprüfen unter welchen Bedingungen das "10s Timeout" ausgelößt wird?

TC macht kein Timeout bei der Datenverbindung.

Frage 2) Kann es sein, dass sehr kleine Antwortzeiten dazu führen das es auf Seiten des Commanders zu Problemen kommt?

Sollte eigentlich nicht sein - oder erwartet der Server die TLS-Negotiation schon vor dem LIST-Befehl?

[seh]

Nein, am Handshake kann es nach unserer Meinung nicht liegen. Das "Code Beispiel" war in der Hinsicht aber vielleicht etwas irreführend vereinfacht:
Die entsprechende Codestrecke beinhaltet natürlich auch die Option für ein TLS Handshake.

Code: Select all

 fdatactx:=SSL_CTX_new(TLSv1_server_method); 

Fakt ist aber 'eh, dass der TC gar nicht erst damit in Berührung kommt, sondern die FTP-Data Verbindung vorher (10s nach unserem ACK im TCP 3-Wege Handshake) von der Gegenstelle mit einem FIN auf TCP-Ebene beendet wird. Ob ursächlich durch den TC oder eine andere System-Routine wäre jetzt zu klären.

Wir haben hier bereits überlegt, ob der Fehler vielleicht innerhalb der Openssl-dll verursacht wird, wenn wir mit einem vermeintlich extrem schnellen TCP Verbindungsaufbau die Initialisierung "überfahren" ?!

Vielleicht sollten wir zu Testzwecken unser System einfach mal "künstlich" verlangsamen und ein paar hundert "gedenk-milisekunden" einpflegen? Zumindest würden wir dann die Antwortzeiten aus dem "Gut-Fall" passen ...

Noch einmal: Das TLS Handshake findet nicht mal ansatzweise statt, sondern vielmehr wird die bereits etablierte TCP Verbindung für FTP-Data nach 10s Schweigen aktiv vom System des TC beendet.

SEH

[seh]

Ähm, da habe ich meinen vorherige Antwort doch glatt zu schnell abgesetzt und den letzten Teil vergessen ...

Sollte eigentlich nicht sein - oder erwartet der Server die TLS-Negotiation schon vor dem LIST-Befehl?

Vielleicht haben wir hier des Pudels Kern: Wir erwarten in der gegebenen Situation definitiv ein TLS Handshake, welches vom TC kommen sollte. Kann es sein, das der TC (oder eine sub-routine) für 10s auf irgendetwas von uns wartet und dann die Verbindung abgebaut wird?

[ghisler(Author)]

Nein, eigentlich nicht!

Gäbe es eine Möglichkeit, dass Sie einen Ihrer Printserver testweise ans Internet hängen würden (öffenliche IP), und mir die Logindaten per e-mail melden würden? So könnte ich im Debugger testen, ob auf Seiten des Total Commander etwas schief läuft...

[seh]

Das sollte kein Problem darstellen! Ich werde mich gleich morgen früh darum kümmern und einen passenden Aufbau machen. Vielen Dank für das Angebot.