netbeans icon indicating copy to clipboard operation
netbeans copied to clipboard
verified publisher icon apache

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

Open fabienfs opened this issue 1 year ago • 5 comments

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:

  • The issue does not occur when using other FTP clients like FileZilla Client.
  • I have tried various configurations in both NetBeans and FileZilla Server, including different TLS versions and passive/active modes, but the problem persists.
  • It seems that NetBeans is unable to resume the TLS session for the data connection after the control connection is established.
  • No problem when I use Pure FTP (FTP without encryption with TLS)
  • FileZilla Server is in last version (1.8.2) and use TLS 1.2 minimum

Suggestions for Resolution:

  • Investigate the handling of TLS sessions in NetBeans, especially in how it resumes or establishes a new TLS session for data connections.
  • Provide an option in NetBeans to disable the requirement for TLS session resumption, if possible.

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

fabienfs avatar Sep 03 '24 20:09 fabienfs

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.

obspsr avatar Oct 02 '24 17:10 obspsr

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.

matthiasblaesing avatar Oct 02 '24 17:10 matthiasblaesing

I retract. no comments, End of story. Serge

obspsr avatar Oct 02 '24 19:10 obspsr

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.

matthiasblaesing avatar Oct 06 '24 11:10 matthiasblaesing

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.

obspsr avatar Oct 06 '24 12:10 obspsr

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

  • jdk.tls.client.enableSessionTicketExtension=true, https://github.com/iterate-ch/cyberduck/commit/c0efa1f417 <- other Java based FTP clients with Filezilla support like Cyberduck are a good source for reference
  • jdk.tls.useExtendMasterSecret=false (but I am not sure about this)
  • --add-open for several modules for the reflection stuff
  • (works only for TLS1.2)

markiewb avatar Nov 15 '24 10:11 markiewb

because i use java 21 and try to figure out the other way to implement Finally, i found this article to fix problem, and work in TLS1.2

ref: https://issues.apache.org/jira/browse/NET-408?focusedCommentId=17800496&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17800496

TommyWU-20170416 avatar Aug 22 '25 09:08 TommyWU-20170416