JSSE classes in FTPS WAS FTPS submission -legal issues
7 answers - 12207 bytes -

Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
/**
*
* This class extends {@link } to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see #connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String, int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress localAddress, int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String, int)
*/
public void connect(String address, int port) throws SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the AUTH SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException {
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg) throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
Regards,
Rory Winston wrote:
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
>Thank you for this explanation. It is good to actually look at the
>code instead of making assumptions, which is what I have been doing.
>>
>The JSSE's jar does not provide javax.net.ssl versions of the
>com.sun.net.ssl interfaces And, after doing a little research, I find
>that there are differences between JSSE 1.0.3 and the packages in JDK
>1.4, such that there is no backward compatibility. Basically, JSSE
>1.0.x is a prototype, a hack through which Sun worked out the bugs,
>culminating in the better implementation that they released in 1.4.
>They did not just move the JSSE.jar code into JDK 1.4. They also
>improved it.
>>
>Since these are new classes for us, I think it makes little sense to
>tie into backward compatibility from the start, when that backward
>compatibility is already out of date. I don't think there is a clean
>way to have one code base that will work the way we'd like it for both
>cases.
>>
>Therefore, I think the solution for this is for Jakarta Commons Net to
>take Rory Winston's suggestion and start a new branch of Commons Net
>for JDK 1.4 only (for this and other reasons) and maintain two
>branches for awhile, the current HEAD branch for 1.3 compatibility and
>the new branch for 1.4. The new branch can use the javax.ssl.net
>classes, the old one can use com.sun.net.
>>
>>
>Jose Juan Montiel wrote:
>>
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>
>
>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>
>>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.1 | | 12915 bytes |
| 
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( );
(new PrintCommandListener(new PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
--
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
--
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
>
>
>
/**
*
* This class extends {@link } to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see #connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String, int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress localAddress, int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String, int)
*/
public void connect(String address, int port) throws SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the AUTH SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException {
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg) throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
>
>
>
>
Regards,
>
>
>
Rory Winston wrote:
>Stevw
>>
>I think that's a great suggestion. It moves us forward without
>necessarily sacrificing backwards compatability.
>>
>I have had a look at the classes written by Jose and Paul, and
>incorporated them into my local branch copy. I had to make one minor
>change to get them to work, but other than that they seem to work well.
>I set up a test FTPS server using FileZilla on my local machine and
>wrote some client code:
>>
>FtpsClient client = new FtpsClient();
>
>client.connect("127.0.0.1");
>(new
>PrintCommandListener(new PrintWriter(System.out)));
>client.login("user", "pass");
>client.cwd("test");
>
>for (FTPFile file : client.listFiles()) {
>System.out.println(file.getName());
>}
>
>Stream out = new FStream("c:\\temp\\test.war");
>client.retrieveFile("test.war", out);
>client.disconnect();
>>
>and it seems to work a treat. If we are agreed that we should go down
>this parallel branch route, then I can move the JDK_1_4_BRANCH to
>something more sensible (i.e. Daniel's suggestion a while back to make
>the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
>stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
>>
>Rory
>>
>Steve Cohen wrote:
>>
>
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>
>>
>
>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.2 | | 14757 bytes |
| 
Hi.
Thanks for your reply. I did try that but still dont see anything more that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1", 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( );
(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
>Hi Rory.
>>
>I tried the apache Jakarta FTPSClient to connect to filezilla ftps
>listening
>on port 990.
>>
>When I use ftps.connect("localhost", 990); it does not get connected.
>>
>FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
>System.out.println("");
>
>client.connect("127.0.0.1",990);
>System.out.println("");
>client.getStatus();
>System.out.println("");
>>
>>
>Appreciate any tips. Thanks.
>>
>Here's the code I downloaded from Apache Jakarta:
>>
>/*
>* Copyright 2001-2005 The Apache Software Foundation
>*
>* Licensed under the Apache License, Version 2.0 (the "License");
>* you may not use this file except in compliance with the License.
>* You may obtain a copy of the License at
>*
>*
>*
>* Unless required by applicable law or agreed to in writing, software
>* distributed under the License is distributed on an "AS IS" BASIS,
>* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or
>implied.
>* See the License for the specific language governing permissions and
>* limitations under the License.
>*/
>>
>>
>import java.io.BufferedReader;
>import java.io.BufferedWriter;
>import java.io.IException;
>import java.io.InputStreamReader;
>import StreamWriter;
>import java.net.InetAddress;
>import java.net.Socket;
>import java.net.SocketException;
>import java.security.KeyStore;
>>
>import ;
>import javax.net.ssl.SSLContext;
>import javax.net.ssl.SSLSocket;
>import javax.net.ssl.TrustManager;
>>
>import ;
>import ;
>>
>>
>>
>/**
>*
>* This class extends {@link } to add
>* the necessary methods that implement SSL/TLS-FTPS.
>*
>*/
>public class FTPSClient extends FTPClient {
>>
>// Represent the method to the FTP command AUTH
>private String sslContext;
>
>// Secure context (can be "TLS" or "SSL")
>private SSLContext context;
>
>private String pbsz;
>private String prot;
>>
>private BufferedReader _controlInput_;
>>
>private BufferedWriter ;
>>
>
>/**
> * Default constructor that selects some default options (TLS
>encryption)
> *
> */
>public FTPSClient() {
>this("JCEKS", "TLS", "password", "0", "P");
>}
>
>
>/**
> *
> * Constructor that initializes the secure connection.
> *
> * @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
>JCEKS
>for Java 1.4
> * @param sslContext Type of the instance SSLContext, can be SSL or TLS.
> * @param password The password to access the KeyStore.
> * @param pbsz Protection buffer size (Use 0 to indicate streaming)
> * @param prot The protection level for the data channel
> */
>public FTPSClient(String keyStoreName, String sslContext, String
>password,
>String pbsz, String prot) {
>this.sslContext = sslContext;
>this.pbsz = pbsz;
>this.prot = prot;
>
>try {
>KeyStore keyStore = KeyStore.getInstance(keyStoreName);
>
>keyStore.load(null, password.toCharArray());
>>
>KeyManagerFactory keyManagerFactory =
>KeyManagerFactory.getInstance(());
>
>keyManagerFactory.init(keyStore, password.toCharArray());
>>
>this.context = SSLContext.getInstance(sslContext);
>>
>this.context.init(
>(),
>new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
>);
>} catch (Exception e) {
>e.printStackTrace();
>}
>}
>
>/**
> * @see
>#connect(java.net.InetAddress,
>int, java.net.InetAddress, int)
> */
>public void connect(InetAddress address, int port, InetAddress
>localAddress, int localPort) throws SocketException, IException
>{
>System.out.println(" In 1 ");
>super.connect(address, port, localAddress, localPort);
>
>this.secure(this.pbsz,this.prot);
>}
>>
>/**
> * @see
>#connect(java.net.InetAddress,
>int)
> */
>public void connect(InetAddress address, int port) throws
>SocketException,
>IException
>{
>System.out.println(" In 2 ");
>super.connect(address, port);
>
>this.secure(this.pbsz,this.prot);
>}
>>
>/**
> * @see #connect(java.lang.String,
>int,
>java.net.InetAddress, int)
> */
>public void connect(String address, int port, InetAddress localAddress,
>int
>localPort) throws SocketException, IException
>{
>System.out.println(" In 3 ");
>super.connect(address, port, localAddress, localPort);
>
>this.secure(this.pbsz,this.prot);
>}
>>
>/**
> * @see #connect(java.lang.String,
>int)
> */
>public void connect(String address, int port) throws SocketException,
>IException
>{
>System.out.println("FTPSClient In 4 ");
>System.out.println("Address=" + address);
>System.out.println("Port=" + port);
>super.connect(address, port);
>
>this.secure(this.pbsz,this.prot);
>}
>
>/**
> *
> * Initialize the secure connection with the FTP server, throw the AUTH
>SSL
>o TLS command.
> * Get the socket with the server, starting the "handshake" making the
>socket, with a layer of securety,
> * and initializing the stream of connection.
> *
> *
> * @param pbsz Protection Buffer Size: "0" is a good value
> * @param prot Data Channel Protection Level:
> * Posible values:
> * C - Clear
> * S - Safe
> * E - Confidential
> * P - PrivateType of secure connection
> *
> * @throws IException If there is any problem with the connection.
> */
>protected void secure(String pbsz, String prot) throws IException {
>this.sendCommand("AUTH", sslContext);
>
>SSLSocket socket =
>(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
>this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
>
>socket.startHandshake();
>>
>this._socket_ = socket;
>
>this._controlInput_ = new BufferedReader(new
>InputStreamReader(socket.getInputStream(), getControlEncoding()));
> = new BufferedWriter(new
>StreamWriter(Stream(), getControlEncoding()));
>>
>this.setSocketFactory( new FTPSSocketFactory(this.context));
>>
>this.sendCommand("PBSZ", pbsz);
>this.sendCommand("PRT", prot);
>}
>>
>/**
> * @see
>#_openDataConnection_(java.lang.String,
>int)
> */
>protected Socket _openDataConnection_(int command, String arg) throws
>IException {
>Socket socket = super._openDataConnection_(command, arg);
>if (socket != null) {
>((SSLSocket)socket).startHandshake();
>}
>return socket;
>}
>>
>}
>>
>>
>>
>>
>Regards,
>>
>>
>>
>Rory Winston wrote:
>
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new
FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.3 | | 13638 bytes |
| 
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1", 990);
regards,
--
Rory Winston wrote:
>Can you attach a PrintCommandListener to the client, so you can see the
>commands being passed over the wire?
>>
>FTPSClient client = new FTPSClient( );
>(new PrintCommandListener(new
>PrintWriter(System.out)));
>
>Then you can see what is actually happening.
>>
>Cheers
>Rory
>>
>>
>>
>M wrote:
>
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
/**
*
* This class extends {@link } to add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress localAddress,
int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int)
*/
public void connect(String address, int port) throws SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the AUTH
SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException {
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg) throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
Regards,
Rory Winston wrote:
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new
FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement FTPS
(in the way that Paul did and I modified, maybe there is another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of (jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>
>To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
>For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>>
>>
>
>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.4 | | 14974 bytes |
| 
Hi.
Yes I did generate the certificate and tested using filezilla client. It
worked from filezilla client though.
I updated apache's secure code
meaning commented:
//this.sendCommand("PBSZ", pbsz);
//this.sendCommand("PRT", prot);
It got connected but not the login now
220-FileZilla Server version 0.9.18 beta
220-written by Tim Kosse (Tim.Kosse (AT) gmx (DOT) de)
220 Please visit
AUTH SSL
234 Using authentication type SSL
1
2
3
4
5
Connected
Is Connected:true
USER test
Exception in thread "main"
Connection closed
without indication.
at (FTP.java:267)
at (FTP.java:460)
at (FTP.java:520)
at (FTP.java:670)
at (FTPClient.java:637)
at TestFTPS.main(TestFTPS.java:31)
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
//FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1");
System.out.println(" Connected ");
System.out.println("Is Connected:" + client.isConnected());
client.login("test", "test");
System.out.println("Is Connected:" + client.isConnected());
System.out.println(" Passed Login ");
Appreciate any advise.
regards,
Rory Winston wrote:
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about
this)
2. Have you generated the server certificate yourself?
M wrote:
>Hi.
>Thanks for your reply. I did try that but still dont see anything more
>that
>would be helpful. I see an entry in the filezilla server but says not
>logged in.
>>
>FTPSClient client = new FTPSClient();
> //client.setReaderThread(false);
>(new PrintCommandListener(new
>PrintWriter(System.out)));
>client.connect("127.0.0.1", 990);
>
>regards,
>>
>>
>Rory Winston wrote:
>
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( );
(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
/**
*
* This class extends {@link } to
add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or
TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress
localAddress,
int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int)
*/
public void connect(String address, int port) throws SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the
AUTH
SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException {
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg) throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
Regards,
Rory Winston wrote:
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work
well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new
FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I
find
that there are differences between JSSE 1.0.3 and the packages in JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a clean
way to have one code base that will work the way we'd like it for
both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net
to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility
and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement
FTPS
(in the way that Paul did and I modified, maybe there is another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the
stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of
(jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't
work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.5 | | 15968 bytes |
| 
What JDK are you using?
M wrote:
Hi.
enough, I took out the code where you pass the login and password, in
my FTPSClient (i.e. //client.login("test","test");) and got connected.
However, whenever I did a command listing, it will just hang like before.
so anything to do like
//client.cwd("temp");
//client.list();
will hang
btw. I took the latest FTPSClient code from Apache too.
--
M wrote:
>Hi.
>>
>Yes I did generate the certificate and tested using filezilla client. It
>worked from filezilla client though.
>>
>I updated apache's secure code
>>
>meaning commented:
>//this.sendCommand("PBSZ", pbsz);
>//this.sendCommand("PRT", prot);
>>
>>
>It got connected but not the login now
>>
>220-FileZilla Server version 0.9.18 beta
>220-written by Tim Kosse (Tim.Kosse (AT) gmx (DOT) de)
>220 Please visit
>AUTH SSL
>234 Using authentication type SSL
>1
>2
>3
>4
>5
>Connected
>Is Connected:true
>USER test
>Exception in thread "main"
>Connection closed
>without indication.
>at (FTP.java:267)
>at (FTP.java:460)
>at (FTP.java:520)
>at (FTP.java:670)
>at (FTPClient.java:637)
>at TestFTPS.main(TestFTPS.java:31)
>>
>FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
> //FTPSClient client = new FTPSClient();
>//client.setReaderThread(false);
> (new PrintCommandListener(new
>PrintWriter(System.out)));
> client.connect("127.0.0.1");
> System.out.println(" Connected ");
> System.out.println("Is Connected:" + client.isConnected());
> client.login("test", "test");
> System.out.println("Is Connected:" + client.isConnected());
> System.out.println(" Passed Login ");
>>
>Appreciate any advise.
>>
>regards,
>>
>Rory Winston wrote:
>
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about
this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything more
that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1", 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see the
commands being passed over the wire?
FTPSClient client = new FTPSClient( );
(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or
implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
/**
*
* This class extends {@link } to
add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3 y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or
TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() }, null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress
localAddress,
int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see #connect(java.lang.String,
int)
*/
public void connect(String address, int port) throws SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the
AUTH
SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making
the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException {
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(), true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg) throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
Regards,
Rory Winston wrote:
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one minor
change to get them to work, but other than that they seem to work
well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new
FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to
make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0 release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at the
code instead of making assumptions, which is what I have been doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I
find
that there are differences between JSSE 1.0.3 and the packages in
JDK
1.4, such that there is no backward compatibility. Basically, JSSE
1.0.x is a prototype, a hack through which Sun worked out the bugs,
culminating in the better implementation that they released in 1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a
clean
way to have one code base that will work the way we'd like it for
both
cases.
Therefore, I think the solution for this is for Jakarta Commons Net
to
take Rory Winston's suggestion and start a new branch of Commons Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility
and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement
FTPS
(in the way that Paul did and I modified, maybe there is
another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it
doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a
classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the
stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of
(jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl. Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't
work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
--
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.6 | | 16214 bytes |
| 
Hi.
its IBM java version "1.4.2_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)
Java HotSpot(TM) Client VM (build 1.4.2_04-b05, mixed mode)
regards,
Rory Winston wrote:
What JDK are you using?
M wrote:
>Hi.
>>
>enough, I took out the code where you pass the login and password,
>in
>my FTPSClient (i.e. //client.login("test","test");) and got connected.
>>
>However, whenever I did a command listing, it will just hang like before.
>>
>so anything to do like
>>
>//client.cwd("temp");
>//client.list();
>>
>will hang
>>
>btw. I took the latest FTPSClient code from Apache too.
>>
>>
>M wrote:
>
Hi.
Yes I did generate the certificate and tested using filezilla client. It
worked from filezilla client though.
I updated apache's secure code
meaning commented:
//this.sendCommand("PBSZ", pbsz);
//this.sendCommand("PRT", prot);
It got connected but not the login now
220-FileZilla Server version 0.9.18 beta
220-written by Tim Kosse (Tim.Kosse (AT) gmx (DOT) de)
220 Please visit
AUTH SSL
234 Using authentication type SSL
1
2
3
4
5
Connected
Is Connected:true
USER test
Exception in thread "main"
Connection
closed
without indication.
at (FTP.java:267)
at (FTP.java:460)
at (FTP.java:520)
at (FTP.java:670)
at (FTPClient.java:637)
at TestFTPS.main(TestFTPS.java:31)
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
//FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1");
System.out.println(" Connected ");
System.out.println("Is Connected:" + client.isConnected());
client.login("test", "test");
System.out.println("Is Connected:" + client.isConnected());
System.out.println(" Passed Login ");
Appreciate any advise.
regards,
Rory Winston wrote:
I've tried this with Filezilla server, and it worked fine for me. Some
initial issues I had:
1. Home dirs not being set up correctly (Filezilla will complain about
this)
2. Have you generated the server certificate yourself?
M wrote:
Hi.
Thanks for your reply. I did try that but still dont see anything
more
that
would be helpful. I see an entry in the filezilla server but says not
logged in.
FTPSClient client = new FTPSClient();
//client.setReaderThread(false);
(new PrintCommandListener(new
PrintWriter(System.out)));
client.connect("127.0.0.1", 990);
regards,
Rory Winston wrote:
Can you attach a PrintCommandListener to the client, so you can see
the
commands being passed over the wire?
FTPSClient client = new FTPSClient( );
(new PrintCommandListener(new
PrintWriter(System.out)));
Then you can see what is actually happening.
Cheers
Rory
M wrote:
Hi Rory.
I tried the apache Jakarta FTPSClient to connect to filezilla ftps
listening
on port 990.
When I use ftps.connect("localhost", 990); it does not get
connected.
FTPSClient client = new FTPSClient("JKS","SSL","password","0","P");
System.out.println("");
client.connect("127.0.0.1",990);
System.out.println("");
client.getStatus();
System.out.println("");
Appreciate any tips. Thanks.
Here's the code I downloaded from Apache Jakarta:
/*
* Copyright 2001-2005 The Apache Software Foundation
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
*
*
* Unless required by applicable law or agreed to in writing,
software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHUT WARRANTIES R CNDITINS F ANY KIND, either express or
implied.
* See the License for the specific language governing permissions
and
* limitations under the License.
*/
import java.io.BufferedReader;
import java.io.BufferedWriter;
import java.io.IException;
import java.io.InputStreamReader;
import StreamWriter;
import java.net.InetAddress;
import java.net.Socket;
import java.net.SocketException;
import java.security.KeyStore;
import ;
import javax.net.ssl.SSLContext;
import javax.net.ssl.SSLSocket;
import javax.net.ssl.TrustManager;
import ;
import ;
/**
*
* This class extends {@link }
to
add
* the necessary methods that implement SSL/TLS-FTPS.
*
*/
public class FTPSClient extends FTPClient {
// Represent the method to the FTP command AUTH
private String sslContext;
// Secure context (can be "TLS" or "SSL")
private SSLContext context;
private String pbsz;
private String prot;
private BufferedReader _controlInput_;
private BufferedWriter ;
/**
* Default constructor that selects some default options (TLS
encryption)
*
*/
public FTPSClient() {
this("JCEKS", "TLS", "password", "0", "P");
}
/**
*
* Constructor that initializes the secure connection.
*
* @param keyStoreName Type of instance KeyStore, JKS for Java 1.3
y
JCEKS
for Java 1.4
* @param sslContext Type of the instance SSLContext, can be SSL or
TLS.
* @param password The password to access the KeyStore.
* @param pbsz Protection buffer size (Use 0 to indicate streaming)
* @param prot The protection level for the data channel
*/
public FTPSClient(String keyStoreName, String sslContext, String
password,
String pbsz, String prot) {
this.sslContext = sslContext;
this.pbsz = pbsz;
this.prot = prot;
try {
KeyStore keyStore = KeyStore.getInstance(keyStoreName);
keyStore.load(null, password.toCharArray());
KeyManagerFactory keyManagerFactory =
KeyManagerFactory.getInstance(());
keyManagerFactory.init(keyStore, password.toCharArray());
this.context = SSLContext.getInstance(sslContext);
this.context.init(
(),
new TrustManager[] { (TrustManager) new FTPSTrustManager() },
null
);
} catch (Exception e) {
e.printStackTrace();
}
}
/**
* @see
#connect(java.net.InetAddress,
int, java.net.InetAddress, int)
*/
public void connect(InetAddress address, int port, InetAddress
localAddress, int localPort) throws SocketException, IException
{
System.out.println(" In 1 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.net.InetAddress,
int)
*/
public void connect(InetAddress address, int port) throws
SocketException,
IException
{
System.out.println(" In 2 ");
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.lang.String,
int,
java.net.InetAddress, int)
*/
public void connect(String address, int port, InetAddress
localAddress,
int
localPort) throws SocketException, IException
{
System.out.println(" In 3 ");
super.connect(address, port, localAddress, localPort);
this.secure(this.pbsz,this.prot);
}
/**
* @see
#connect(java.lang.String,
int)
*/
public void connect(String address, int port) throws
SocketException,
IException
{
System.out.println("FTPSClient In 4 ");
System.out.println("Address=" + address);
System.out.println("Port=" + port);
super.connect(address, port);
this.secure(this.pbsz,this.prot);
}
/**
*
* Initialize the secure connection with the FTP server, throw the
AUTH
SSL
o TLS command.
* Get the socket with the server, starting the "handshake" making
the
socket, with a layer of securety,
* and initializing the stream of connection.
*
*
* @param pbsz Protection Buffer Size: "0" is a good value
* @param prot Data Channel Protection Level:
* Posible values:
* C - Clear
* S - Safe
* E - Confidential
* P - PrivateType of secure connection
*
* @throws IException If there is any problem with the connection.
*/
protected void secure(String pbsz, String prot) throws IException
{
this.sendCommand("AUTH", sslContext);
SSLSocket socket =
(SSLSocket)this.context.getSocketFactory().createS ocket(this._socket_,
this.getRemoteAddress().getHostAddress(), this.getRemotePort(),
true);
socket.startHandshake();
this._socket_ = socket;
this._controlInput_ = new BufferedReader(new
InputStreamReader(socket.getInputStream(), getControlEncoding()));
= new BufferedWriter(new
StreamWriter(Stream(), getControlEncoding()));
this.setSocketFactory( new FTPSSocketFactory(this.context));
this.sendCommand("PBSZ", pbsz);
this.sendCommand("PRT", prot);
}
/**
* @see
#_openDataConnection_(java.lang.String,
int)
*/
protected Socket _openDataConnection_(int command, String arg)
throws
IException {
Socket socket = super._openDataConnection_(command, arg);
if (socket != null) {
((SSLSocket)socket).startHandshake();
}
return socket;
}
}
Regards,
Rory Winston wrote:
Stevw
I think that's a great suggestion. It moves us forward without
necessarily sacrificing backwards compatability.
I have had a look at the classes written by Jose and Paul, and
incorporated them into my local branch copy. I had to make one
minor
change to get them to work, but other than that they seem to work
well.
I set up a test FTPS server using FileZilla on my local machine and
wrote some client code:
FtpsClient client = new FtpsClient();
client.connect("127.0.0.1");
(new
PrintCommandListener(new PrintWriter(System.out)));
client.login("user", "pass");
client.cwd("test");
for (FTPFile file : client.listFiles()) {
System.out.println(file.getName());
}
Stream out = new
FStream("c:\\temp\\test.war");
client.retrieveFile("test.war", out);
client.disconnect();
and it seems to work a treat. If we are agreed that we should go
down
this parallel branch route, then I can move the JDK_1_4_BRANCH to
something more sensible (i.e. Daniel's suggestion a while back to
make
the 1.4+ branch version 2), maybe NET_2_0_0. We can use the
com.sun.*
stuff for the 1.3 branch (which will probably be our 1.5.0
release)?
Rory
Steve Cohen wrote:
Thank you for this explanation. It is good to actually look at
the
code instead of making assumptions, which is what I have been
doing.
The JSSE's jar does not provide javax.net.ssl versions of the
com.sun.net.ssl interfaces And, after doing a little research, I
find
that there are differences between JSSE 1.0.3 and the packages in
JDK
1.4, such that there is no backward compatibility. Basically,
JSSE
1.0.x is a prototype, a hack through which Sun worked out the
bugs,
culminating in the better implementation that they released in
1.4.
They did not just move the JSSE.jar code into JDK 1.4. They also
improved it.
Since these are new classes for us, I think it makes little sense
to
tie into backward compatibility from the start, when that backward
compatibility is already out of date. I don't think there is a
clean
way to have one code base that will work the way we'd like it for
both
cases.
Therefore, I think the solution for this is for Jakarta Commons
Net
to
take Rory Winston's suggestion and start a new branch of Commons
Net
for JDK 1.4 only (for this and other reasons) and maintain two
branches for awhile, the current HEAD branch for 1.3 compatibility
and
the new branch for 1.4. The new branch can use the javax.ssl.net
classes, the old one can use com.sun.net.
Jose Juan Montiel wrote:
Hi Steve,
What I think you're missing is that if you put jsse.jar on your
classpath, you can use javax.net.ssl with java 1.3.
maybe i don't explain well, sorry.
The three classes of com.sun.net.ssl that are used for implement
FTPS
(in the way that Paul did and I modified, maybe there is
another)
are
()
com.sun.net.ssl.SSLContext
()
com.sun.net.ssl.TrustManager
()
This classes in JSSE are only in the package com.sun.net.ssl, and
although in JSSE 1.0.3 there are a packege javax.net.ssl, it
doesn't
contain this classes, it contains javax.net.ssl.SSLSocket, a
classes
soon used, to implement FTPS.
And the commons-net team would prefer to go that way because Sun
says that
com.sun.net may go away with some future release, but not
javax.net. Yes, this
would be a small inconvenience for java 1.3 users, but the
stability
is worth it.
This three classes in JDK 1.4.2, were move to
()
javax.net.ssl.SSLContext
()
javax.net.ssl.TrustManager
()
But if you download for example JDK 1.4.2 and look inside of
(jre/lib)
you'll find jsse.jar, the jar where still are com.sun.net.ssl.
Sun,
still mantain compatiblity with JDK 1.3.
And still in JDK 1.5, you'll find jre/lib/jsse.jar.
But when jsse.jar desapear, i offer to modified code
In other way if use ,
javax.net.ssl.SSLContext, javax.net.ssl.TrustManager, ftps don't
work
under JDK 1.3.
I hope explain better, this time.
Then, make that you consider appropiate
Thanks all, for your time.
--
The whole purpose of places like Starbucks is
for people with no decision-making ability
whatsoever to make six decisions just to buy
one cup of coffee. Short, tall, light, dark, caf,
decaf, low-fat, non-fat, etc. So people who
don't know what the hell they're doing or who
on earth they are can, for only $2.95, get not
just a cup of coffee but an absolutely defining
sense of self: Tall. Decaf. Cappuccino.
To unsubscribe, e-mail:
commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail:
commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
>>
>
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org
No.7 | | 501 bytes |
| 
Hmmm,
Well if there is a problem somewhere, its got to be recorded *somehow*.
There are three places it could be:
1. The FileZilla interface
2. The FileZilla logs
3. The output from the FTP Client (i.e. any JSSE exceptions thrown)
So there is nothing in any of these that gives you any clues?
To unsubscribe, e-mail: commons-dev-unsubscribe (AT) jakarta (DOT) apache.org
For additional commands, e-mail: commons-dev-help (AT) jakarta (DOT) apache.org