Error when uploading file with TLS #29
Comments
|
ok, found out this only happens on vsftpd, tried also Do you have any idea's? |
|
What version of vsftpd are you using? |
|
3.0.3
Regards,
Patrick
|
|
So the problem most likely is in a change added to 3.0.3 according to the release notes for vsftpd. More recent releases (2015/2016) of FileZilla added logic to require TLS connected clients to reuse data channel connections. Requiring data session connection reuse breaks the FtpClient. There is an easy way to turn that re-use requirement off in FileZilla. It seems the maintainers of vsftpd included those recommend changes in vsftpd 3.0.3 according to their release notes. "Kill the FTP session if we see session re-use failure. A report from Tim Kosse tim.kosse@filezilla-project.org. (vsftpd-3.0.3pre1)" So for vsftpd 3.0.3 there may be a way to turn off this new feature as can be done in FileZilla. Some have described this solution as a security "kludge" trying to fix or address fundamental problems in the FTP protocol. Obviously to more widely support data connection re-use I will need to make changes to the FtpClient. Its interesting that this is just now showing up. You are the second person to report it in the past few weeks. I am guessing it has taken maybe taken few years to get the 2016 versions of FileZilla and vsftpd into the distros and deployed to servers. |
|
Found this on vsftpd's site. "You can disable this [connection re-use] requirement by changing require_ssl_reuse to NO." |
|
I hoped it will work, but sorry, with Here is my full vsftpd.conf file: |
|
you know, the ftp session isn't killed, I will always get a |
|
So the FTP session consists of two connections. The control channel which is the "session" and that is not getting shutdown and the "data" channel which is the secondary connection opened by your server to all for data to transfer down an assigned server port if you are using Passive FTP. Note that Active FTP sets the data port specifically and the server binds forever to that port. But in Passive FTP the data port is transmitted to the client via the FTP control channel as text. The FTP client then reads that text and turns around and uses it to connect to the FTP server. The errors you are receiving all pertain to the data channel. Have you confirmed that other clients can connect to the same vsftpd server? The reason I ask is that firewalls and whatnot can interfere or block clients from access the server ports used by Passive FTP. |
|
Thank you for the explanation!
Yes I tried with another client. I got a successful connection with WinSCP, so the PC shouldn't be the problem. With Winscp (yes in FTP mode with SSL) I can up and download files without problems.
Regards
Patrick
|
|
Can you clear the vsftpd log, reproduce the failure and provide the error lines from the log so I can see them? Based on your vsftpd profile the log should be in the following location on your FTP server. /var/log/vsftpd.log |
|
Here we go: File exists on /tmp with size 10.138 Bytes... Here the full log: |
|
with winscp with same settings (user/pass/port) it works: |
|
So I installed vsftpd 3.0.3 on my development machine and used some of the settings you posted from your config file. Interestingly vsftpd does not support anything higher than TLS 1.0 in the conf file but it does seem to support it when I connect with TLS v1.2. Oddly I am unable to force TLS v1.2 for clients as there is no option in conf file to do that. Pretty weird. So I am unable to exactly fix the issue. It seems to be related around the TLS connections and how they expect the connection to be presented on the data connection. I was able to disable the TLS Session ID requirement but then I got the error "Failure Reading Network Stream." The FtpsClient relies on the Mono and .NET run-times to manage and reuse TLS sessions. I have no way to force the data connections to reuse TLS Session IDs when they connect on the data channel. That is a very low level trick which some FTP clients are able to get away with if they are using something like openssl to negotiate the connections. Below are the settings I used in the vsftpd conf file. At this point I don't think I can really fix the issue as I still don't understand why vsftpd doesn't like the TLS connections but FileZilla has no issue with it. Note that FileZilla is my test FTP server that I make sure I am compatible with. `#debug switches #ssl config |
|
You can force TLS1.2 with What does this error means? I will help you as much as I can! See this log, maybe it helps (extended with Look here, maybe it helps: here |
|
See here
And here I see in the log "ssl_received_shutdown"
See shutdown See discussion And maybe this Winscp on my PC send's this shutdown to my vsftpd server: |
|
So the .NET/Mono SslStream doesn't give me a whole lot of control as to how the SSL/TLS protocol is working. Session ID caching, reusing connections, opening and closing TLS is all handled inside the SslStream which is powerful when it works as you want it to. Interestingly FileZilla is accepting the FtpsClient without any issue as long as I disable the security "feature" for requiring reuse of SSL Session IDs. I think you are correct and have got some good DEBUG information there concerning SSL. What I am seeing in my testing is that the PASV command is accepted by vsftpd, the STOR command is also accepted, and data is fully transferred from the client to server in its entirety and written to the file system by vsftpd. The next step accepted by other FTP servers such as FileZilla is to close the connection to signify the transfer is complete by the client. But vsftpd doesn't like that. It is expecting to receive a very specific SSL protocol shutdown state of 3 before the connection is actually closed by the client. The SslStream doesn't seem to do it in the way the vsftpd demands but FileZilla accepts. I imagine the vsftpd maintainers added this code when they implemented the SSL Session ID reuse logic and it bled into the normal flow of code even if the SSL Session ID reuse is disabled. What happens after I shutdown the TLS passive data connection after transferring all the bytes for a STOR command is that vsftpd gets all upset and sends the following response. Could we ignore that 426 error? That's one way to go about it. 4xx errors are defined as the following.
Another individual reported similar problematic behavior with the SslStream and he went to great lengths to reflect into the Microsoft SSI APIs to force SslStream to send a close_notify code 3 to the server before closing the connection. This solution might work but it also causes another problem which is that it only works on .NET and not Mono. I will give it a try on my Windows VM later in the week and see if that makes any difference. |
|
Did you find out any work-around? Thx |
|
I did not. |
|
For what it is worth, some 4 years later, on Ubunto 20.04, and with a different application running .NET's FtpWebRequest, I was able to fix this by adding to vsftpd.conf. Which one fixed I don't know but I'm slowly backing away.... |
|
Wow. My money is on "require_ssl_reuse=NO". |
|
require_ssl_reuse=NO didn't do it on its own. Even though the man page says they all default to NO, so specifying these three should be a no-op, the Ubuntu build must have changed some of these defaults is my guess. Probably why people are banging their heads. |
Hi I have a problem on Windows7 and Window10 when uploading files.
I tried this code:
And I will get an error with
An error occurred while putting fileName '/tmp/test.txt'. (Last Server Response: Failure reading network stream. ConnectionClosedSoTransferAborted)but the file is there and then the check.IsConnectedsaysTrueand the second file will be created with the same error but the check after says alsoTrueand the second file is also uploaded...This error happens with TLS1.0 up to TLS1.2 with and without proxy connections (others not tested).
It also happens with:
test.PutFile("d:\test.txt", "/tmp/test2.txt")BUT it doesn't happen with:
What's wrong?
Thx
Patrick
The text was updated successfully, but these errors were encountered: