You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Leif John Korshavn (JIRA)" <ji...@apache.org> on 2011/02/09 14:53:57 UTC
[jira] Created: (NET-354) FTPSClient not properly supporting CCC
and PROT P
FTPSClient not properly supporting CCC and PROT P
-------------------------------------------------
Key: NET-354
URL: https://issues.apache.org/jira/browse/NET-354
Project: Commons Net
Issue Type: Bug
Components: FTP
Affects Versions: 2.2
Environment: Applies to all environments
Reporter: Leif John Korshavn
FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
SSLSocket socket =
(SSLSocket) ssf.createSocket(_socket_, ip, port, false);
Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
_socket.close();
_socket = _plainsocket;
...
And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019719#comment-13019719 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
Sebb, where exactly is the current trunk source for 3.0-SNAPSHOT?
I checked out anonymously from http://svn.apache.org/repos/asf/commons/proper/net/trunk commons-net
but I can't seem to find my patch applied here.... Also, this looks like even older than 2.2, perhaps 2.0...
Found the URL at http://commons.apache.org/net/source-repository.html
I have also requested a trial version from Globalspace of the same FTP server that Erick uses.
But I do believe I can see why this is failing for Erick.
FTPSClient._connectAction_:
protected void _connectAction_() throws IOException {
// Implicit mode.
if (isImplicit) sslNegotiation();
super._connectAction_();
// Explicit mode.
if (!isImplicit) {
execAUTH();
sslNegotiation();
}
}
This code initializes an implicit FTPS socket pretty much in the same way it does for explicit, but notice that super._connectAction_ comes AFTER implicit sslNegotiation. This means that all initialization of the socket in superclasses, is done on the SSLSocket, not on the underlying socket.
This could have consequences later on, when re-establishing a plain socket. I will investigate further.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020204#comment-13020204 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
@Sebb: Yes, indeed you are right, the patch is present. I guess I stumbled a bit when clicking around in my IDE.
I am still waiting for Globalspace to accept my request for a trial version of their product. According to their online doc, it seems as allowing CCC is a configurable option on the server independent of explicit/implicit FTPS.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019770#comment-13019770 ]
Sebb commented on NET-354:
--------------------------
@Leif: Glad to see that CCC over explicit SSL works OK for you.
The FTP jar is a subset, containing FTP + support classes only. Apparently some people wanted a smaller jar.
The code in the snapshot was built from http://svn.apache.org/repos/asf/commons/proper/net/trunk and *does* include your patch. FTPSClient should be at r1091783 currently if your workspace is up to date.
Like you, I'm not sure that CCC should apply to implicit SSL; but if it does, then something needs to be fixed.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Leif John Korshavn updated NET-354:
-----------------------------------
Attachment: CCC_bugs_in_FTPSClient.patch
Attached a patch to fix the aforementioned errors.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Reopened] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb reopened NET-354:
----------------------
Can you provide a test case?
i.e. some sample code that shows the faulty behaviour?
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13022118#comment-13022118 ]
Sebb commented on NET-354:
--------------------------
According to the sequence diagram in RFC 4217, both ends should initiate shutdown:
CCC ---------------------------------------------->
<---------------------------------------------- 200
TLSshutdown() <-------------------------------------> TLSshutdown()
So if the EFT server cannot handle that, it is probably broken.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Tim Barton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13030122#comment-13030122 ]
Tim Barton commented on NET-354:
--------------------------------
GlobalSCAPE's EFT did not expect the encrypted close_notify after the CCC was issued, so it tried to interpret the encrypted close_notify as the result of the command which followed the CCC. EFT 6.3.1 can now be configured to expect the encrypted close_notify upon termination of TLS by the CCC command.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Erick Lichtas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13021626#comment-13021626 ]
Erick Lichtas commented on NET-354:
-----------------------------------
Calling close on the client side appears to be notifying the server of an ssl shutdown. The EFT server i was testing against appears to be having issues when this notification is sent, whereas works, when we do not call socket.close() and simple discard the ssl socket wrapper. Other server's such as ProFTPd seem to leave it up to the client to shutdown ssl which works great with the patch applied to Commons NET. There also appears to be a potential timing issue if both the server and client initiate the ssl shutdown.
My question is, what is the correct behavior? It makes sense that it be left up to the client to shutdown the SSL as the CCC is initiated by the client. I'm curious if CuteFTP (which is made by the same company as the EFT server) works with ProFTPd. I'm guessing it will not.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019569#comment-13019569 ]
Sebb commented on NET-354:
--------------------------
@Leif: can you try the CCCTester with explicit mode using the current Net snapshot?
i.e. change the line "ftps = new FTPSClient(true);" to "ftps = new FTPSClient(false);"
This works for me with pro-ftpd on Ununtu.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13025077#comment-13025077 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
I have still not heard anything from GlobalScape regarding my request for a trial version of their EFT server. I will do a renewed request today. It is not possible to download a trial version without first being approved. Erick, I sent you a mail with a question in this regard, have you read it?
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029835#comment-13029835 ]
Sebb commented on NET-354:
--------------------------
So are we agreed that the current behaviour of NET is correct?
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019483#comment-13019483 ]
Sebb commented on NET-354:
--------------------------
Thanks, that's useful. Did not realise you were using implicit mode.
Unfortunately the default pro-ftpd server available with Ubuntu does not seem to have implicit SSL built in.
However, the test code works OK with the current Net snapshot [1] when using explicit SSL mode.
Does it work OK for you in explicit mode?
I realise that implicit mode is somewhat different, but it would be useful to know if explicit mode at least is working for you.
[1] https://repository.apache.org/content/repositories/snapshots/commons-net/commons-net/3.0-SNAPSHOT/
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029847#comment-13029847 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
In my opinion, yes.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (NET-354) FTPSClient not properly
supporting CCC and PROT P
Posted by "Erick Lichtas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019368#comment-13019368 ]
Erick Lichtas edited comment on NET-354 at 4/13/11 3:12 PM:
------------------------------------------------------------
Sample program CCCTester.java is attached. This program connects to an FTPS server, sets the data channel protection level, runs the CCC command, and lists the home directory. This program was run using jre 1.5.0_22 on windows. It is using commons-net 2.2 with the patch provided in this jira case.
My tests were performed using a trial version of GlobalScapes EFT server with CCC enabled. And below is the output of the sample program:
REPLY: 220 EFT Server Enterprise 6.1.0 Build 10.30.2009.48 * UNREGISTERED COPY *
COMMAND: USER test
REPLY: 331 Password required for test.
COMMAND: PASS **********
REPLY: 230-This is an * UNREGISTERED COPY * of GlobalSCAPE EFT Server.
230 Login OK. Proceed.
COMMAND: PBSZ 0
REPLY: 200 PBSZ Command OK. Protection buffer size set to 0.
COMMAND: PROT P
REPLY: 200 PROT Command OK. Using Private data connection
COMMAND: CCC
REPLY: 200 Clear Command Channel Successful.
COMMAND: SYST
org.apache.commons.net.ftp.FTPConnectionClosedException: Connection closed without indication.
at org.apache.commons.net.ftp.FTP.__getReply(FTP.java:298)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:495)
at org.apache.commons.net.ftp.FTPSClient.sendCommand(FTPSClient.java:486)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:537)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:586)
at org.apache.commons.net.ftp.FTP.syst(FTP.java:1504)
at org.apache.commons.net.ftp.FTPClient.getSystemType(FTPClient.java:2074)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2511)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2276)
at org.apache.commons.net.ftp.FTPClient.listFiles(FTPClient.java:2322)
at test.ftps.CCCTester.test(CCCTester.java:42)
at test.ftps.CCCTester.main(CCCTester.java:101)
was (Author: elichtas):
Sample program to connect to an FTPS server, set the data channel protection level, run the CCC command, and list the home directory.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029161#comment-13029161 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
Finally I got a download from GlobalScape. I have installed their EFT Server 6.3.0 for trial on Windows. I have been able to reproduce Ericks result, and I have some interesting observations:
Apache FTPS client (rel 2.2) implicit mode -> CCC OK
Apache FTPS client (rel 2.2) explicit mode -> CCC OK
Apache FTPS client (3.0-SNAPSHOT) implicit mode -> CCC FAILS!
Apache FTPS client (3.0-SNAPSHOT) explicit mode -> CCC FAILS!
So this means that Erick indeed has discovered some new behaviour introduced in the current snapshot (i.e. my patch). It also applies to explicit mode. I will investigate further.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Erick Lichtas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Erick Lichtas updated NET-354:
------------------------------
Attachment: CCCTester.java
Sample program to connect to an FTPS server, set the data channel protection level, run the CCC command, and list the home directory.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Erick Lichtas (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019068#comment-13019068 ]
Erick Lichtas commented on NET-354:
-----------------------------------
I also noticed that the CCC implementation was not correct. I have applied this patch locally and it does not appear that the autoClose flag set when creating the SSLSocket works as expected when the SSLSocket.close() is called.
If _socket_.close() is called during the handling of the CCC command, the subsequent command (for example SYST) fails with java.net.SocketException: Software caused connection abort: socket write error. The error specifically happens during the getReply() when reading a line from the controlInput which comes back null. I've tested this on Windows using java 1.5 and 1.6 and got the same results. I'm not sure if it behaves any different on linux.
Caused by: java.net.SocketException: Software caused connection abort: socket write error
at java.net.SocketOutputStream.socketWrite0(Native Method)
at java.net.SocketOutputStream.socketWrite(SocketOutputStream.java:92)
at java.net.SocketOutputStream.write(SocketOutputStream.java:136)
at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:202)
at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:272)
at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:276)
at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:122)
at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:212)
at java.io.BufferedWriter.flush(BufferedWriter.java:236)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:490)
at org.apache.commons.net.ftp.FTPSClient.sendCommand(FTPSClient.java:486)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:550)
at org.apache.commons.net.ftp.FTP.sendCommand(FTP.java:599)
at org.apache.commons.net.ftp.FTP.pasv(FTP.java:948)
at org.apache.commons.net.ftp.FTPClient._openDataConnection_(FTPClient.java:607)
at org.apache.commons.net.ftp.FTPSClient._openDataConnection_(FTPSClient.java:521)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2724)
at org.apache.commons.net.ftp.FTPClient.initiateListParsing(FTPClient.java:2698)
If I leave the autoClose option true and simply discard the SSLSocket:
// _socket_.close();
_socket_ = _plainSocket
...
all subsequent commands are executed without problems.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019701#comment-13019701 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
OK, I ran CCCTester in explicit mode with commons-net 3.0-SNAPSHOT (commons-net-3.0-20110413.141705-1.jar)
(BTW, I see there is a "ftp"-snapshot aswell, what is in it? commons-net-3.0-20110413.141705-1-ftp.jar )
Here is the log from my run:
REPLY: 220-FTPD1 IBM FTP CS V1R10 at bmvs0, 05:54:59 on 2011-04-14.
220 Connection will close if idle for more than 5 minutes.
COMMAND: AUTH TLS
REPLY: 234 Security environment established - ready for negotiation
COMMAND: USER <masked out>
REPLY: 331 Send password please.
COMMAND: PASS **********
REPLY: 230 FTZ is logged on. Working directory is "FTZ.".
COMMAND: PBSZ 0
REPLY: 200 Protection buffer size accepted
COMMAND: PROT P
REPLY: 200 Data connection protection set to private
PBSZ and PROT
COMMAND: CCC
REPLY: 200 CCC command successful
CCC
COMMAND: SYST
REPLY: 215 MVS is the operating system of this server. FTP Server is running on z/OS.
COMMAND: PORT 172,22,14,16,135,146
REPLY: 200 Port request OK.
COMMAND: LIST
REPLY: 125 List started OK
REPLY: 250 List completed successfully.
FILE: BRODCAST.MSGS
As you can see, it works perfectly also for me.
Since only Erick is able to test in implicit mode, I will take some time today to study the FTPSClient code for possible incompatibilities with CCC and implicit mode, with special attention on the SSLSocket-object and its I/O-streams.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb resolved NET-354.
----------------------
Resolution: Fixed
Fix Version/s: 3.0
Thanks, patch applied
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Sebb (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Sebb resolved NET-354.
----------------------
Resolution: Fixed
As far as I can tell, CCC is working OK, at least when used from Windows connecting to pro-ftpd on Ubuntu.
I also tried vsftpd and pure-ftpd but neither seems to support CCC.
If the current code does not work for you, please re-open with full details.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13019512#comment-13019512 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
Interesting case. Are you sure it really is the client that closes the connection with an exception? Could it be the server refusing to process clear text commands, and hence shutting the connection down.
Is CCC really supported in implicit mode? In my mind, implicit mode is an "encrypted only" channel from start to end with even a dedicated port number.
The chapter "Scope of use" in this article confirms my opinion: http://en.wikipedia.org/wiki/FTPS
Erick, I believe you when you say that CCC works for the subsequent commands when not explicitly closing down the SSLSocket, I merely want to point out that this may be a gray area with regards to how specific the specs/rfcs are. You do know that explicit mode is the recommended mode?
Unfortunately, I am not able to run your test code, as I only use the FTPS client against a FTP Server on IBM Mainframe, supporting only explicit mode and with rigid corporate firewalls between me and it. The code with the patch I submitted is in daily use in test, the application will go live in May.
I am also afraid of simply discarding the SSLSocket object, as this in a long running server could lead to a significant leakage of resources/open files (I might be wrong, but...)
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC
and PROT P
Posted by "Leif John Korshavn (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13029790#comment-13029790 ]
Leif John Korshavn commented on NET-354:
----------------------------------------
Ok, so I have reached the same conclusion as Erick: The EFT Server has a problem with the close_notify alert that terminates the TLS session.
According to RFC 2246 section 7.2.1 (http://www.rfc-editor.org/in-notes/rfc2246.txt) this alert is mandatory, especially when data is supposed to be exchanged after TLS termination, which of course is the whole reason for using CCC.
Hence, skipping the close operation on SSLSocket is not ok; this was the reason for me to add the close in the first place, as I had problems with FTPS to IBM Mainframe. Also backed up by this bug report http://www-01.ibm.com/support/docview.wss?uid=isg1PK77240
I will submit this as a bug to GlobalScape with a reference to this Jira issue.
> FTPSClient not properly supporting CCC and PROT P
> -------------------------------------------------
>
> Key: NET-354
> URL: https://issues.apache.org/jira/browse/NET-354
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
> Affects Versions: 2.2
> Environment: Applies to all environments
> Reporter: Leif John Korshavn
> Fix For: 3.0
>
> Attachments: CCCTester.java, CCC_bugs_in_FTPSClient.patch
>
>
> FTPSClient does not behave properly after issuing CCC (Clear Command Channel). Proper behaviour is to close SSLSocket, but keep underlying connection without SSL open.
> To achieve this, the SSLSocket should be created with "false", like this on line 255 (of FTPSClient v2.2)
> SSLSocket socket =
> (SSLSocket) ssf.createSocket(_socket_, ip, port, false);
> Furthermore, on sendCommand CCC, sslSocket must be closed before setting _socket = _plainsocket on line 493:
> _socket.close();
> _socket = _plainsocket;
> ...
> And finally, it is wrong to set socket factory to null on line 500 of the same method; this is set properly in exexPROT and should not be reset on CCC.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira