Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

TLS Timeout on LIST/Insecure Data connection #252

Open
emma-clicknclear opened this issue Apr 11, 2021 · 9 comments
Open

TLS Timeout on LIST/Insecure Data connection #252

emma-clicknclear opened this issue Apr 11, 2021 · 9 comments
Labels
bug A defect or bug that affects the original indended use of the application on hold

Comments

@emma-clicknclear
Copy link

emma-clicknclear commented Apr 11, 2021

Have been trying to trace down why this issue keeps occurring, but so far I cannot. I have configured ftp-srv (running in Node due to custom project with a custom Filesystem override for virtual FS - that all works fine so far).

However, for TLS connections I get the following error when using Cyberduck:

"directive":"LIST","level":50,"err":{"message":"operation timed out","name":"TimeoutError","stack":"TimeoutError: operation timed out

If I connect using FileZilla, I get the error that "This server does not support session resumption on the data connection."

This is my constructor for the FileSystem override if it helps:

image

The Account type is a user account. The connection is passed in from callback function args on ftpServer.on('login') out of the data object as describe in the docs. Any ideas what could be going wrong here, as this is the only issue I currently have preventing things from being completely smooth!

Good job on this project btw. :)

@Yooooomi
Copy link

I had the same issue, I fixed it using the comments in #59 concerning the pasv_url

@emma-clicknclear
Copy link
Author

I had the same issue, I fixed it using the comments in #59 concerning the pasv_url

Unfortunately I bumped into that one already and am already using that method:

image

I've also tried passing the server's URL directly into the pasv_url area. I would imagine non-TLS would also have some issues if this were messed up, but only TLS is having the issues. I also have the ports forwarded properly for the pasv port range, and that works fine for non-TLS connections.

@matt-forster
Copy link
Contributor

matt-forster commented Apr 19, 2021

Hey all, I was AFK last week, but just letting you know I have eyes on this and hopefully, we can start working towards a solution. I'll have a more detailed response in the next couple of days.

@matt-forster matt-forster self-assigned this Apr 19, 2021
@matt-forster matt-forster added the bug A defect or bug that affects the original indended use of the application label Apr 19, 2021
@doesdev
Copy link

doesdev commented May 20, 2021

You may not be having the same issue as I was, but I'll note it here in case it helps.

First let me state, I still get the This server does not support session resumption on the data connection warning from FileZilla (still trying to figure that out).

That said, I found after switching to explicit that the tls handshake was failing. For me, this was because I was using an SNICallback without a default certificate in the tls options. Once I resolved the handshake issues under explicit and switched back to implicit the timeout errors went away for me.

@doesdev
Copy link

doesdev commented Aug 6, 2021

There is more to this one. It seems the underlying cause of the timeouts (based on similar issues reported in various other FTP projects) is the lack of session resumption. It may be different based on client, but I did get confirmation from a Filezilla team member that the only method of session resumption they support is that laid out in the TLS 1.3 specification, which is in-band PSK based resumption.

Unfortunately it appears that this is not supported in Node.js at all at this point. Compounding the issue the related docs are completely out of line with the TLS 1.3 specification. For me this led to many days of digging before I realized that the docs are straight up inaccurate.

So, as of now (unless I'm missing something and this is simply a documentation issue) it appears that this issue cannot be addressed until support for PSK based session resumption is added to Node.

Please add your voice to this issue in Node core

I've created an issue for that but any support voiced there would be appreciated as it doesn't seem session resumption is something too many folks care about with HTTP, but it seems much more necessary for FTPS.

@matt-forster
Copy link
Contributor

Wow, great exploration there - thank you so much for the info!

@mcfriend99
Copy link

mcfriend99 commented Feb 10, 2022

I'm experiencing this issue as well only in my case, the premise differs.

I keep getting the error below when running the server in a docker container even without TLS enabled.

{"message":"operation timed out","name":"TimeoutError","stack":"TimeoutError: operation timed out\n at afterTimeout (/app/node_modules/bluebird/js/release/timers.js:46:19)\n at Timeout.timeoutTimeout [as _onTimeout] (/app/node_modules/bluebird/js/release/timers.js:76:13)\n at listOnTimeout (node:internal/timers:559:17)\n at processTimers (node:internal/timers:502:7)"},"msg":"operation timed out","time":"2022-02-10T23:48:28.562Z","v":0}

I have tried everything on this page, but none of them works.

@matt-forster
Copy link
Contributor

@mcfriend99 If the issue you are having is not TLS related - then we may want to create a separate bug report, or even a question in the discussions to get to the bottom of it - your handler may just not be returning correctly?

@DenisLevkovets
Copy link

@matt-forster As for me, the way to solve this problem was to allow my firewall to accept a connection from my ftp client (in my case CyberDuck)

@matt-forster matt-forster removed their assignment Aug 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A defect or bug that affects the original indended use of the application on hold
Projects
None yet
Development

No branches or pull requests

6 participants