search

apache / netbeans

Apache NetBeans
https://netbeans.apache.org/
Apache License 2.0
2.68k stars 855 forks source link

FTP TLS Session Not Resumed - Unable to Upload Files to FileZilla Server #7727

Open fabienfs opened 2 months ago

fabienfs commented 2 months ago

Apache NetBeans version

Apache NetBeans 22

What happened

When using NetBeans to connect to a FileZilla FTP server via FTP over TLS (FTPS), the IDE successfully establishes the initial control connection and navigates through directories. However, when attempting to upload a file, the data connection fails with an error stating that the TLS session could not be resumed. This issue specifically arises during the transition from the control connection to the data connection, preventing any file uploads from being completed. The server responds with a 425 Unable to build data connection: TLS session of data connection not resumed error, indicating that the TLS handshake for the data connection could not be successfully resumed or established.

Language / Project Type / NetBeans Component

PHP Application from remote server

How to reproduce

  1. Configure a FileZilla FTP Server (version 1.8.2) to use FTP over TLS (explicit mode).
  2. In NetBeans (version 22), configure an FTP connection in Explicit FTP using TLS in passive mode
  3. Attempt to upload a file to the server.

Expected Behavior:

The file should upload successfully without any issues.

Actual Behavior:

The upload fails with the following error message: 425 Unable to build data connection: TLS session of data connection not resumed.

The server log shows the following error: GnuTLS error -110: The TLS connection was non-properly terminated.

Environment:

Product Version: Apache NetBeans IDE 22
Java: 22.0.2; Java HotSpot(TM) 64-Bit Server VM 22.0.2+9-70
Runtime: Java(TM) SE Runtime Environment 22.0.2+9-70
System: Mac OS X version 14.6.1 running on aarch64; UTF-8; fr_BE (nb)

Additional Information:

Suggestions for Resolution:

Did this work correctly in an earlier version?

Apache NetBeans 22

Operating System

Mac OS Sonoma (version 14.6.1)

JDK

Java: 22.0.2; Java HotSpot(TM) 64-Bit Server VM 22.0.2+9-70 / Runtime: Java(TM) SE Runtime Environment 22.0.2+9-70

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

No response

Are you willing to submit a pull request?

No

obspsr commented 1 month ago

I confirm the problem on releases 21, 22 et 23. I tried to connect to my Hostinger repos. with filezilla (which works well) Thanks for coop.. Serge.

matthiasblaesing commented 1 month ago

After the C++ tools dropping, Netbeans becomes less and less usefull ... I

Please stop this. NB is opensource, you are free to contribute. Complaining does not help. C++ tools were not dropped, noone stepped up to maintain them, noone including you.

obspsr commented 1 month ago

I retract. no comments, End of story. Serge

matthiasblaesing commented 1 month ago

So I had look at this and from my POV its a mess. The problem is, that FileZilla forces clients to reuse the TLS session used for the control channel on the data channel. Seems, that problem wracks havoc with various clients and my TL;DR take away is: FTP is dead, don't use it.

The longer version: Java implements session resumptions for TLS. However it only allows that only for the same hostname/port pair. The TLS sessions are held in a map keyed by this. But even breaking into the JDK code and faking an entry holding the same session for hostname/datachannel-port as for hostname/controlchannel-port does not help (Idea from https://gist.github.com/riyaz-ali/48fb486f51c258b4e92c2d2be30c35c4, adjusted as getHost does not work anymore).

Messing with TLS settings also did not help on my test setup (https://issues.apache.org/jira/browse/NET-408).

My final straw was adding bouncy-castle TLS to NetBeans and using its implementation for the connection (inspired by https://github.com/bcgit/bc-java/issues/458). Wireshark indicated, that the session was established, the client side disagreed and still did not work.

I stop at this point.

obspsr commented 1 month ago

Thanks for giving your POV, and I agree fully; I have also lost time on wireshark, changed java17-23, with no luck. I use NB for Symfony php applic. devel, and C++ remotely for telescope INDI control devel. it works perfectly on NB-21... ... which makes me unhappy about C++ lag... BUT we don´t absolutely need the last IDE version ;-) ... For closing, if I set protocol: PureFtp, mode: active, with PR:49152-65534 upload works perfectly (with all the FTP usual risks... So far, not so bad... :(() Serge.

markiewb commented 1 week ago

So I had look at this and from my POV its a mess. The problem is, that FileZilla forces clients to reuse the TLS session used for the control channel on the data channel. Seems, that problem wracks havoc with various clients and my TL;DR take away is: FTP is dead, don't use it.

The longer version: Java implements session resumptions for TLS. However it only allows that only for the same hostname/port pair. The TLS sessions are held in a map keyed by this. But even breaking into the JDK code and faking an entry holding the same session for hostname/datachannel-port as for hostname/controlchannel-port does not help (Idea from https://gist.github.com/riyaz-ali/48fb486f51c258b4e92c2d2be30c35c4, adjusted as getHost does not work anymore).

Messing with TLS settings also did not help on my test setup (https://issues.apache.org/jira/browse/NET-408).

My final straw was adding bouncy-castle TLS to NetBeans and using its implementation for the connection (inspired by bcgit/bc-java#458). Wireshark indicated, that the session was established, the client side disagreed and still did not work.

I stop at this point.

We had to connect to such a filezilla FTP server once too and our team succeeded in providing a solution. I cannot disclose the whole solution, but some tips for the journey.

See https://docs.spring.io/spring-integration/reference/ftp/advanced-configuration.html#ftps-and-shared-sslsession as a base.

To make it work past JDK8 several additional changes (next to the reflection patching of the sessionHostPortCache of the SSLSessionContext) have to be made