|
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
|
