Go Back   FlashFXP Forums > >

Project: FlashFXP Bug Reports Ticket Tools
ID: 42 Category: General / Unknown
Title: Secure transfer problems Status: Closed (Fixed / Implemented)
Severity: Medium Version: 3.4.1 (Beta)

Senior Member
DayCuts
07-17-2007, 11:57 PM
Secure transfer problems

Possible secure transfer negotiation issues, maybe caused by failure to renegotiate when circumstances change? not entirely sure...

For each scenerio assume that for all sites involved the following options are all enabled.
Secure File Listing, Secure File Transfers (Upload/Download), Secure Site to Site Transfers, Turn Off Fingerprint checking on Data Connection.

1. Connect to two sites and securely fxp a file between them (L>R). Attempt to 'view' (ctrl+v) a file on the side that previously SENT the file (SIDE L, not the side that recieved it as this seems to work fine). Result as follows...

[14:35:45] [R] PRET RETR test.txt
[14:35:45] [R] 200 OK, will use C00 for upcoming transfer
[14:35:45] [R] PASV
[14:35:45] [R] 227 Entering Passive Mode (***).
[14:35:45] [R] Opening data connection IP: *** PORT: ***
[14:35:46] [R] RETR test.txt
[14:35:46] [R] Connected. Negotiating TLSv1 session..
[14:35:46] [R] 150 File status okay; about to open data connection from ***.
[14:35:47] [R] error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number
[14:35:47] [R] Failed TLSv1 negotiation, disconnected
[14:35:47] [R] 426- Illegal client handshake msg, 1
[14:35:47] [R] 426 Illegal client handshake msg, 1
[14:35:47] [R] Transfer Failed!

2. As a continuation of the above issue, after side L fails to securely download-and-view a file, fxp from R>L no longer works (as it previously would have prior to the failed view attemp), however L>R continues to function.

[14:46:34] [R] TYPE I
[14:46:35] [R] 200 Command okay
[14:46:35] [L] TYPE I
[14:46:35] [L] 200 Command okay
[14:46:35] [R] PRET RETR 100kb
[14:46:35] [R] 200 OK, will use *** for upcoming transfer
[14:46:35] [R] SSCN ON
[14:46:36] [R] 220 SSCN:CLIENT METHOD
[14:46:36] [R] PASV
[14:46:36] [R] 227 Entering Passive Mode (***).
[14:46:36] [L] PORT ***
[14:46:36] [L] 200 FXP allowed. If you're not FXPing then set your IP to *** (usually in firewall settings)
[14:46:36] [L] STOR 100kb
[14:46:36] [L] 150 File status okay; about to open data connection to ***.
[14:46:36] [R] RETR 100kb
[14:46:37] [R] 150 File status okay; about to open data connection from ***.
[14:46:37] [L] 426- Illegal client handshake msg, 1
[14:46:37] [L] 426 Transfer failed, deleting file
[14:46:37] [R] ABOR
[14:46:37] [R] 426- Illegal client handshake msg, 1
[14:46:37] [R] 426 Illegal client handshake msg, 1
[14:46:38] [R] 226 Closing data connection
[14:46:38] [L] ABOR
[14:46:38] [L] 226 Closing data connection
[14:46:38] [L] Transfer Failed!

3. As a further continuation after a failed 'view' on side L, if you disconnect side R and connect to an alternate site with secure transfers/fxp, any attempt to transfer from R>L will now also fail.

Note: this occurs completely regardless of the ssl method used

The only way to truely clean the slate is to disconnect both sides then connect/reconnect and continue. There were other scenarios in which these issues occured however i am either unable to reproduce them reliably or they dont seem to be occuring any longer.

As was stated at the top of report, this 'seems' to be somehow related to certain negotiation/handhsake data being incorrectly reused or not renegotiated when the circumstances of the transfer suggest that they probably should be? This is the best idea i can come up with at this point with the limited knowledge of how the ssl dll's function and no idea what those errors mean in technical terms.

Regardless, it can become quite irritating to have to completely disconnect both sides before continuing. (i often pause a queue to view a file before resuming the queue, this is much easier than opening another session, connecting, navigating to correct location, etc)

Windows 2000 Professional, FlashFXP build 1179
FlashFXP Developer
bigstar
07-18-2007, 02:44 AM
Re: Secure transfer problems

I tested this behavior using a couple different sites and I wasn't able to reproduce it.

I suspect this might be an issue related to using drFTPD or perhaps PRET.. It's really not clear to me, The logs you provided were good, however not really enough information for this type of issue.
Senior Member
DayCuts
07-18-2007, 06:08 AM
Re: Secure transfer problems

Dont have the time right now to do any extensive testing, or provide much more info, but i did just do some quick tests and it does infact seem to depend on the ftp server combinations. I will have to look into it some more and see what other info or differences i can find between servers.

From the quick tests i found the following..

servu+g6ftpd (both win) works fine
servu+drftpd (win/nix) works fine
servu+servu (both win) works fine
g6ftpd+g6ftpd (both win) works fine
drftpd+g6ftpd (nix/win) fails
drftpd+drftpd (nix/nix) fails

as you can see i was only able to reproduce the issue with dr+dr or dr+g6 at this time.

What further information could i provide to help figure out what is causing this? (even if its not flashfxp related), its possible that it is indeed something with dr and/or pret, although dr+su caused no issues under any circumstances :s

heading to work but will check back tomorrow hopefully
FlashFXP Developer
bigstar
07-18-2007, 04:50 PM
Re: Secure transfer problems

I don't have any drftpd sites for testing this..

I might be able to figure it out with a complete ftp session log, but it may be very difficult and more time consuming. You can send the log directly to me if needed.
Senior Member
DayCuts
07-20-2007, 02:02 AM
Re: Secure transfer problems

sent full log via private message
Senior Member
ArtX
07-20-2007, 02:06 PM
Re: Secure transfer problems

i can confirm this bug with flashfxp+glftpd - it only happens when you tick secure uploads/downloads

error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure, think that is the full error - i shall be re-installing my linux server sometime in the next week or so and will report back, should mention it is with a self compiled dsa cert from glftpd's installer
FlashFXP Developer
bigstar
07-20-2007, 11:29 PM
Re: Secure transfer problems

I figured out the problem with the help of DayCuts and it is a bug in FlashFXP. It will be fixed in the next beta release. Build 1184 and up.
Senior Member
DayCuts
07-21-2007, 12:46 AM
Re: Secure transfer problems

Ah, cool
Senior Member
DayCuts
07-27-2007, 02:51 AM
Re: Secure transfer problems

Just wanted to clarify that this bug seems to be fixed, after doing some tests and attempting to reproduce with my own examples i have yet to encounter any problems.

FlashFXP is now issuing SSCN OFF prior to attempting to recieve a file (local viewing as in examples) and reissuing SSCN ON prior to the next secure fxp transfer.

Nice job
FlashFXP Developer
bigstar
07-29-2007, 07:27 AM
Re: Secure transfer problems

Thank you, I appreciate you bringing this issue to my attention
Ticket Tools
Subscribe to this Ticket


Posting Rules
You may not post new tickets

Smilies are On
[IMG] code is On
HTML code is Off


All times are GMT -5. The time now is 10:03 AM.

Parts of this site powered by vBulletin Mods & Addons from DragonByte Technologies Ltd. (Details)