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

FTP: using TLS on data channel blocks connection reuse #4329

Closed
Zenju opened this issue Sep 11, 2019 · 4 comments
Closed

FTP: using TLS on data channel blocks connection reuse #4329

Zenju opened this issue Sep 11, 2019 · 4 comments

Comments

@Zenju
Copy link
Contributor

Zenju commented Sep 11, 2019

Hi,

when setting CURLOPT_USE_SSL to CURLUSESSL_ALL, recent libcurl builds have become extremely slow. After debugging it became clear why:

Even when reusing the same easy handle, the control connection is closed after every FTP data download, instead of being kept open.

Looking at Wireshark the logs are filled with lots of "AUTH SSL", when there should in fact be only a single one.

Reproduce:

curl --user demo:password --ssl-reqd ftp://test.rebex.net//pub/ ftp://test.rebex.net//pub/example/

Expected: only 1 "AUTH SSL"
Actual: 2 "AUTH SSL"

The problem is caused by the following commit:
3f5da4e#diff-7dafef8d70eee3940c9184e4e4e93448

The changes in the commit issue a
connclose(conn, "TLS close_notify");
when the FTP data channel is finished with the transfer, but this closes the whole FTP connection, including the control channel! Although the easy handle is reused, it has to authenticate again.

Solution: Maybe skip the changes of the above commit in the FTP case?

@bagder
Copy link
Member

bagder commented Sep 11, 2019

For the FTP case it should only be a concern if the "close notify" message is received on the primary control connection, not on the data connection - which I suspect is what happens for you.

Can you verify that when this happens wrongly for you, is the num argument to that function holding the value 1 ?

@Zenju
Copy link
Contributor Author

Zenju commented Sep 12, 2019

Yes num = 1, i.e. the data channell is receiving 0 bytes from SSL_read().

bagder added a commit that referenced this issue Sep 12, 2019
... for FTPS transfers, we are destined to get it on the data connection
without that being a signal to close the control connection!

Regression since 3f5da4e (7.65.0)

Reported-by: Zenju on github
Fixes #4329
@bagder
Copy link
Member

bagder commented Sep 12, 2019

I hope #4340 fixes the problem for you?

@Zenju
Copy link
Contributor Author

Zenju commented Sep 12, 2019

Yes, it does: I'm seeing only a single "AUTH SSL" in my test case (and runtime went down from 14 to 6 sec). Thank you!

@bagder bagder closed this as completed in a56a47a Sep 12, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Dec 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Development

Successfully merging a pull request may close this issue.

2 participants