[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152044#comment-17152044
]
Erick Lichtas commented on NET-408:
---
I cache it the _connectAction_() method. Something like this:
{noformat}
@Override
protected void _connectAction_() throws IOException {
if (useTlsResumption){
// cache the address if resuming tls
tlsResumptionAddress = new
InetSocketAddress(_socket_.getInetAddress(), _socket_.getPort());
}
// Implicit mode.
if (isImplicit) {
sslNegotiation();
}
super._connectAction_();
// Explicit mode.
if (!isImplicit) {
execAUTH();
sslNegotiation();
}
}{noformat}
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152043#comment-17152043
]
Erick Lichtas commented on NET-408:
---
[~eolivelli] - you will need to make sure you pass in the appropriate host
address and port of the control channel when constructing the factories in the
FTPSClient. That is what the tlsResumptionAddress object does for me in the
code above.
Good luck!
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17152035#comment-17152035
]
Erick Lichtas commented on NET-408:
---
[~jtoivonoja] - This case went quiet for a long time and my patch, which was
still in the works at the time, has since been finalized and has been in use
for a few years now. I've updated the attached set of libs.
The biggest problem is that the data connection is on a separate port than the
control connection. So when java looks up the TLS session for the ftp data
connection on port 3 (as an example), it doesn't find one - the control
connection where the session was originally create for port 21. The patch I've
attached will instruct the SSLEngine being created to use the original control
channel host and port. This doesn't impact the socket connection itself, but
will instruct the JVM to use an existing SSL session if it exists.
I've added a newer zip file 'FTPSClientWithTLSResumption' with an
org.apache.commons.net.io.ext package. Copy that package into your project and
add the following code block to the appropriate location in the execPROT method
of the FTPSClient.java class
{code:java}
// Added to execProt command of the FTPSClient.java
if (useTlsResumption) {
ChannelSslSocketFactory sslSocketFactory = new ChannelSslSocketFactory(
context);
sslSocketFactory.setControlHost(tlsResumptionAddress.getAddress().getHostAddress());
sslSocketFactory.setControlPort(tlsResumptionAddress.getPort());
setSocketFactory(sslSocketFactory);
ChannelSslServerSocketFactory sslServerSocketFactory = new
ChannelSslServerSocketFactory(
context);
sslServerSocketFactory.setControlHost(tlsResumptionAddress.getAddress().getHostAddress());
sslServerSocketFactory.setControlPort(tlsResumptionAddress.getPort());
setServerSocketFactory(sslServerSocketFactory);
}
else {
setSocketFactory(new FTPSSocketFactory(context, _socketFactory_));
setServerSocketFactory(new FTPSServerSocketFactory(context));
}
{code}
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Lichtas updated NET-408:
--
Attachment: FTPSClientWithTLSResumption.zip
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Lichtas updated NET-408:
--
Attachment: (was: FTPSClientWithTLSResumption.zip)
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
>Priority: Major
> Attachments: BCFTPSClient.java, FTPSClientWithTLSResumption.zip,
> PTFTPSClient.java, ftpes.jpg, proftpd.conf
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (NET-408) problem connecting to ProFTPD with FTPES
[
https://issues.apache.org/jira/browse/NET-408?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Lichtas updated NET-408:
--
Attachment: FTPSClientWithTLSResumption.zip
Hi everyone,
I have adjusted the implementation of the FTPSClient to support TLS resumption
in a way that is friendly across all JVMs and security providers. I've
essentially implemented some custom SSL sockets and socket factories that use
the SSLEngine and SocketChannels directly for handling SSL encryption and
decryption. These SocketChannels and the encryption/decryption is encapsulated
in Input and Output streams so the changes to existing Commons NET code is
minimal. There's only a couple updates to the SocketClient and FTPSClient
classes in order to swap out the socket factories. I've also added a flag on
the FTPSClient to control whether or not to resume TLS sessions for data
connections.
I have a separate fork of version 3.3 that I've developed this on, but I've
applied the changes to the 3.6 version and ran a couple tests. See the changes
attached (FTPSClientWithTLSResumption.zip).
I've tested this against the Apache Mina FTP server project in addition to the
FileZilla server. TLS resumption is working as expected with FileZilla. I've
tested the changes for Explicit and Implicit SSL, Active and Passive data
connections, as well as clear command channel which is working as expected.
I'm hoping that the development team will adopt these changes so that they can
be utilized and tested by the entire community. If you have any questions,
please let me know.
> problem connecting to ProFTPD with FTPES
>
>
> Key: NET-408
> URL: https://issues.apache.org/jira/browse/NET-408
> Project: Commons Net
> Issue Type: Bug
> Components: FTP
>Affects Versions: 2.2, 3.0
> Environment: ProFTPD 1.3.3d on SUSE Linux Enterprise Server 10.1
> 32bit, Kernel 2.6.16.46-0.12-default (config file attached)
> ProFTPD 1.3.3d on OpenSUSE 64bit Linux 2.6.34.8-0.2-desktop
> Java 1.5
>Reporter: Michael Voigt
> Attachments: BCFTPSClient.java, ftpes.jpg,
> FTPSClientWithTLSResumption.zip, proftpd.conf, PTFTPSClient.java
>
>
> I have a problem with the FTPClient connecting to a ProFTPD server.
> If the server uses the configuration option "TLSProtocol TLSv1", I
> cannot connect to it at all. I recieve the following error message:
> - javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection
> On the server side I see in the log:
> unable to accept TLS connection: protocol error:
> - (1) error:14094416:SSL routines:SSL3_READ_BYTES:sslv3 alert
> certificate unknown
> - TLS/TLS-C negotiation failed on control channel
> If the server uses the configuration option "TLSProtocol SSLv23", I
> can connect to it but I cant transfer any files. In the server log I
> see:
> - starting TLS negotiation on data connection
> - TLSv1/SSLv3 renegotiation accepted, using cipher RC4-MD5 (128 bits)
> - client did not reuse SSL session, rejecting data connection (see
> TLSOption NoSessionReuseRequired)
> - unable to open data connection: TLS negotiation failed
> If I add the NoSessionReuseRequired parameter to the ProFTPD config
> everything works fine.
> Here is my code:
>FTPClient ftpClient = new FTPClient();
>ftpClient = new FTPSClient("TLS");
>// this throws an exception with TLSProtocol TLSv1
>ftpClient.connect(host, port);
>int reply = ftpClient.getReplyCode();
>if (!FTPReply.isPositiveCompletion(reply)) {
>ftpClient.disconnect();
>log.error("The FTP Server did not return a positive
> completion reply!");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_CONNECTION);
>}
>boolean loginSuccessful = ftpClient.login(userName, password);
>if (!loginSuccessful) {
>log.error("Login to the FTP Server failed! The
> credentials are not valid.");
>throw new
> FtpTransferException(ECCUtils.ERROR_FTP_LOGIN);
>}
>ftpClient.execPBSZ(0);
>ftpClient.execPROT("P");
>boolean success = ftpClient.storeFile(fileName, fis);
>if (!success) {
>// this is false if "NoSessionReuseRequired" is not set
>}
> Now my question is if it is generally possible to connect to a server
> with "TLSProtocol TLSv1" or "TLSProtocol SSLv23" without the
> "NoSessionReuseRequired" parameter? Could someone provide a piece of
> example code for this?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (NET-354) FTPSClient not properly supporting CCC and PROT P
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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] [Updated] (NET-354) FTPSClient not properly supporting CCC and PROT P
[ 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] [Issue Comment Edited] (NET-354) FTPSClient not properly supporting CCC and PROT P
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
[ https://issues.apache.org/jira/browse/NET-354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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
