EldoS | Feel safer!

Software components for data protection, secure storage and transfer

FTPS - Zero length file on send

Also by EldoS: CallbackRegistry
A component to monitor and control Windows registry access and create virtual registry keys.
#8163
Posted: 11/11/2008 12:03:49
by Eric Dobrzelewski (Standard support level)
Joined: 09/05/2008
Posts: 11

I'm trying to use the TElSimpleFTPSClient object (.NET 2.0; SBB v6 and v5.2) to push a file to a server over SSL. The server is made by and run at IBM, but I don't know exactly what it is running. I can get the client to connect (using SSL v3; passive or active), but I have to send ClearCommandChannel (CCC) in order for it to not error when I change dirs, get a file list, etc. When I try to push a file, it creates the zero-byte placeholder, but then errors with a "10053". The OnProgress event fires a few times as if it is transfering.

Doing some research, I think that (10053) is a Winsock error typically caused by an abrupt disconnect. I am able to use CuteFTP with the same settings (as far as I can tell) and I can post the file with no problems. I can successfully delete files on the server using the SBB client.

Any ideas?
Thanks.
-Eric
#8165
Posted: 11/11/2008 17:05:12
by Paul Schneider (Standard support level)
Joined: 11/10/2008
Posts: 10

I'm also trying to use the TElSimpleFTPSClient object (.NET 2.0; SBB v6) to push a file to a server over SSL. The server is made by and GlobaScape and running on windows XP SP3.(using SSL v3; passive ), I have to send EncryptDataChannel = false in order for it to not error. When I try to push a file with EncryptDataChannel = Ture it creates the zero-byte placeholder, but then errors with a "10053". I am also able to use CuteFTP to push file successfully.

I shut sown the firewall and tried numberous other ElSimpleFTPSClient settings.
Currently trying differnt cipher settings - I'll keep you posted.

Thanks.
Paul
#8167
Posted: 11/11/2008 23:39:38
by Ken Ivanov (EldoS Corp.)

Please try the following settings:
a) turn off TLS1.1 and TLS1.2 protocol versions (leaving SSL3, TLS1 and optionally SSL2 enabled),
b) set AdjustPasvAddress property to true,
c) set UseSSLSessionResumption to false.

If the above does not help, please try to play with PassiveMode and TransferType properties and check if some combination of them causes the component to work.
#8171
Posted: 11/12/2008 08:25:02
by Eric Dobrzelewski (Standard support level)
Joined: 09/05/2008
Posts: 11

That did not seem to work for me. I had to turn off TLS1 and TLS1.1 to begin with. In .NET there isn't an option for TLS1.2, so I'm assuming it is off. Plus it says it is connecting with SSLv3. I tried all 8 combinations of passive/active mode, passive address adjust, and SSL session resume. I'm setting the transfer type to Binary. If you think that really could be the problem, I can go back and test the other 8 combinations. I did one quick test with ASCII transfer type, but got the same result.

FYI, the defaults for the settings are:
PassiveMode = false
AdjustPasvAddress = true
UseSSLSessionResumption = false

Also FYI, UseSSLSessionResumption is not in the Help doc (HTML) that comes with the install.

Lastly, and this is likely unrelated, whenever I log in to the FTP server using the demo client, I have to issue a CWD twice. (By "command" I mean using the buttons.) If I try to issue a PWD or LIST as the first command I get "Unaccepted server reply (error code is 250)", even though 250 is the expected result there's obviously an exception being raised. If I issue CWD then PWD, it works fine. Here's the output for the first CWD:

>>>CWD /myfolder
<<<250 SITE command successful.
>>>PWD
<<<257 "/" is current directory.
>>>CWD /myfolder
<<<250 CWD command successful.
>>>PWD
<<<257 "/myfolder" is current directory.
#8172
Posted: 11/12/2008 09:58:45
by Mykola Olshevsky (Basic support level)
Joined: 07/07/2005
Posts: 450

Hi.
2Paul Schneider: are you using the latest (3.3.7) version of GlobalScape FTPS server? We tested SBB with it, and everything goes fine, with TLS1.0/AUTH TLS/EncryptDataChannel, and Implicit SSL.

2Eric: for PWD command there is only one defined in RFC 959 success reply, and it is 257. And for CWD command it is 250. Error 10053 means that data connection failed due to some reasons, possibly because of firewall on your or the other side. You can use one of the traffic sniffers (Wireshark is a good one) to see what is sent by CuteFTP and by our demo, and look at the difference between sent/received data.
#8173
Posted: 11/12/2008 10:04:58
by Ken Ivanov (EldoS Corp.)

BTW, have you performed your tests with the sample SimpleFTPSDemo application? It is a good idea to try to upload a file with it, as it includes all the necessary error handling and writes all the session information (including SSL protocol errors) to the log.
#8174
Posted: 11/12/2008 13:17:16
by Eric Dobrzelewski (Standard support level)
Joined: 09/05/2008
Posts: 11

I'm using the demo app with a few enhancements. I've hooked in all of the events except OnBinaryData and have them write out a quick message to the textbox. I've also added checkboxes to tie into the AdjustPasvAddress and UseSSLSessionResumption settings as well as one to have it issue a "CCC" command.

I've downloaded a packet sniffer and took a look at the demo app and CuteFTP side by side. A lot of it is useless because of the SSL (as it should be). I can see it connecting, getting the MOTD, setting the authorization (SSL v3), and exchanging keys. The actual login is encrypted using SSL, but if I follow along with the log generated by the client demo app it looks ok. In fact, when I compare the output of the demo app and that of CuteFTP, they are pretty darn close. They issue the same commands and get the same results. One or two are in a different order, but get the same response.

One thing I noticed with the packet sniffer is that when I get to actually sending the file, SBB is NOT encrypting it with SSL. I can see the contents are clear-text. It appears to handshake and exchange keys with the server at login, but when it tries to send the file it doesn't encrypt it. This goes along with what I saw before when I hooked into the OnProgress event. It would give me progress updates as if it was sending, but in the end would error out.
#8178
Posted: 11/12/2008 23:37:53
by Ken Ivanov (EldoS Corp.)

Quote
One thing I noticed with the packet sniffer is that when I get to actually sending the file, SBB is NOT encrypting it with SSL. I can see the contents are clear-text.

File transfer is done in cleartext if EncryptDataChannel property is set to false. Is it set to false by your code?
#8179
Posted: 11/12/2008 23:38:12
by Ken Ivanov (EldoS Corp.)

I've just recalled one CCC-related issue that had been fixed in the recent build update. The issue causes TElSimpleFTPSClient to work improperly with some servers if ClearCommandChannel is used. Please try to upgrade to the latest build update (6.1.148) and check if it resolves the problem.
#8182
Posted: 11/13/2008 07:04:34
by Eric Dobrzelewski (Standard support level)
Joined: 09/05/2008
Posts: 11

The new release worked. Thanks! My next question is when do you think it will be approved for release? I see that it is still a "beta". In the mean time, this will help me convince my management to approve the upgrade to v6.

Thank you everyone for your help.

As an aside, Eldos folks, would you have any interest in my customized version of the SimpleFTPSDemo code? I've added more switches, some event logging, and a crude "auto scroll" so that the textbox and listview both show the bottom of the content.
Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.

Reply

Statistics

Topic viewed 4058 times

Number of guests: 1, registered members: 0, in total hidden: 0




|

Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!