You are viewing a plain text version of this content. The canonical link for it is here.
Posted to ftpserver-users@mina.apache.org by "West, John C" <Jo...@CITIZENSBANK.com> on 2009/02/03 17:43:41 UTC
RE: SSL setup problems...
So everything is not fine after all.
After dancing around a load of internal networking issues, I'm now
getting:
javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not
enabled or not supported
on the data connection (PASV). Here's my listener config:
<listeners>
<nio-listener name="default" port="30021"
implicit-ssl="false">
<ssl>
<keystore file="conf/keystore.jks"
password="password" key-alias="key" algorithm="IbmX509" />
<truststore file="conf/keystore.jks"
password="password" algorithm="IbmX509" />
</ssl>
<data-connection idle-timeout="60">
<active local-port="40021" />
<passive ports="40021-40049" />
</data-connection>
</nio-listener>
</listeners>
As you can see, I'm not specifying SSL or TLS. The control connection
works fine (over TLS) and then the client tries to open the data
connection using SSLv3 and that's when I get the error. I wrote a quick
app to list out the protocols supported by the jre I'm using and I got
[SSLv3, TLS, TLSv1, SSL, SSL_TLS] so SSLv3 is available.
While the client team tries to figure out how to use TLS for both, I
thought I'd do some investigating. Is leaving the protocol out of the
ssl tag the same as specifying SSL_TLS? Would there be any issues mixing
TLS/SSL?
-----Original Message-----
From: West, John C
Sent: Thursday, January 29, 2009 10:39 AM
To: ftpserver-users@mina.apache.org
Subject: RE: SSL setup problems...
That's what I thought, but he was insistent that the cert is all that's
required.
I generated a new key and installed it, but it still didn't work. It
turned out that the subsequent issue was caused by the client not
playing well with implicit-ssl=true. I changed that and everything works
fine now.
Thanks for your help.
-----Original Message-----
From: Niklas Gustavsson [mailto:niklas@protocol7.com]
Sent: Monday, January 26, 2009 4:43 PM
To: ftpserver-dev@incubator.apache.org
Subject: Re: SSL setup problems...
On Mon, Jan 26, 2009 at 10:26 PM, West, John C
<Jo...@citizensbank.com> wrote:
> I have a keystore (conf/keystore.jks) with one certificate:
> % keytool -list -keystore conf/keystore.jks Enter keystore password:
> password
>
> Keystore type: jks
> Keystore provider: IBMJCE
>
> Your keystore contains 1 entry
>
> xfer, Jan 26, 2009, trustedCertEntry,
> Certificate fingerprint (MD5):
> 80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB
This is not sufficient, you need to have at least a key for the server
to use. You can generate this using keytool -genkey.
> My ftpd.xml has the following configuration:
>
> <listeners>
> <nio-listener name="default" port="30021"
> implicit-ssl="true">
> <ssl protocol="SSL"
> client-authentication="WANT">
Noramlly, you do not need these attributes.
> <keystore file="conf/keystore.jks"
> password="password" key-alias="xfer" algorithm="IbmX509" />
You do not need the key-alias attribute if the keystore only contains
your key. I'm not sure if you need the algorithm, but I would not think
so.
> <truststore file="conf/keystore.jks"
> password="password" algorithm="IbmX509" />
Again, algorithm might not be needed.
That should be it, let us know if it helps or not. We can probably
improve our error logging in this area, I'll have a look at that after
1.0.
/niklas
-----------------------------------------
Use of email is inherently insecure. Confidential information,
including account information, and personally identifiable
information, should not be transmitted via email, or email
attachment. In no event shall Citizens or any of its affiliates
accept any responsibility for the loss, use or misuse of any
information including confidential information, which is sent to
Citizens or its affiliates via email, or email attachment. Citizens
does not guarantee the accuracy of any email or email attachment,
that an email will be received by Citizens or that Citizens will
respond to any email.
This email message is confidential and/or privileged. It is to be
used by the intended recipient only. Use of the information
contained in this email by anyone other than the intended recipient
is strictly prohibited. If you have received this message in error,
please notify the sender immediately and promptly destroy any
record of this email.
RE: SSL setup problems...
Posted by "West, John C" <Jo...@CITIZENSBANK.com>.
Thanks Sai. That was exactly my problem. We downgraded to SSL to fix it
(the client has issues with TLS on AIX).
-----Original Message-----
From: Sai Pullabhotla [mailto:sai.pullabhotla@jmethods.com]
Sent: Wednesday, February 04, 2009 9:45 AM
To: ftpserver-users@mina.apache.org
Subject: Re: SSL setup problems...
This is an issue with IBM's JVM where they decided to change things
around in Java 1.5. The thing that they changed is the implementation of
getInstance() method in SSLContext class.
The SunJVMs work fine with SSL/TLS peer when you initialized the
SSLContext with SSLContext.getInstance("TLS"). The same used to work
fine in IBM's JVM in version 1.4. However, they decided not to do so in
1.5. When I spoke to their Support, they said that they are not going to
change it back bacause they changed it for a reason in the first place.
With the newer IBM's JVM, the call to SSLContext.getInstance("TLS") only
works if the other end is actually using TLS. If the other end uses SSL,
IBM's JSSE thows a handshake exception.
If you want your application to connect to either SSL or TLS, you need
to initialize the SSLContext by passing "SSL_TLS" as the protocol.
More information on this can be found on the IBM's Java web site (I
found it a long time ago, hope you can still find it).
The answer to your question is, there won't be any 'real' issues
specifying "SSL_TLS" other than the fact that you are supporting both
SSL and TLS for your FTP clients. Your server might be vulnerable to all
known issues in SSL v3, if any.
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Tue, Feb 3, 2009 at 10:43 AM, West, John C
<Jo...@citizensbank.com>wrote:
>
>
> So everything is not fine after all.
>
> After dancing around a load of internal networking issues, I'm now
> getting:
> javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3
> not enabled or not supported
>
> on the data connection (PASV). Here's my listener config:
> <listeners>
> <nio-listener name="default" port="30021"
> implicit-ssl="false">
> <ssl>
> <keystore file="conf/keystore.jks"
> password="password" key-alias="key" algorithm="IbmX509" />
> <truststore file="conf/keystore.jks"
> password="password" algorithm="IbmX509" />
> </ssl>
> <data-connection idle-timeout="60">
> <active local-port="40021" />
> <passive ports="40021-40049" />
> </data-connection>
>
> </nio-listener>
> </listeners>
>
>
> As you can see, I'm not specifying SSL or TLS. The control connection
> works fine (over TLS) and then the client tries to open the data
> connection using SSLv3 and that's when I get the error. I wrote a
> quick app to list out the protocols supported by the jre I'm using and
> I got [SSLv3, TLS, TLSv1, SSL, SSL_TLS] so SSLv3 is available.
>
> While the client team tries to figure out how to use TLS for both, I
> thought I'd do some investigating. Is leaving the protocol out of the
> ssl tag the same as specifying SSL_TLS? Would there be any issues
> mixing TLS/SSL?
>
>
>
>
> -----Original Message-----
> From: West, John C
> Sent: Thursday, January 29, 2009 10:39 AM
> To: ftpserver-users@mina.apache.org
> Subject: RE: SSL setup problems...
>
>
> That's what I thought, but he was insistent that the cert is all
> that's required.
>
> I generated a new key and installed it, but it still didn't work. It
> turned out that the subsequent issue was caused by the client not
> playing well with implicit-ssl=true. I changed that and everything
> works fine now.
>
> Thanks for your help.
>
>
>
> -----Original Message-----
> From: Niklas Gustavsson [mailto:niklas@protocol7.com]
> Sent: Monday, January 26, 2009 4:43 PM
> To: ftpserver-dev@incubator.apache.org
> Subject: Re: SSL setup problems...
>
> On Mon, Jan 26, 2009 at 10:26 PM, West, John C
> <Jo...@citizensbank.com> wrote:
> > I have a keystore (conf/keystore.jks) with one certificate:
> > % keytool -list -keystore conf/keystore.jks Enter keystore password:
> > password
> >
> > Keystore type: jks
> > Keystore provider: IBMJCE
> >
> > Your keystore contains 1 entry
> >
> > xfer, Jan 26, 2009, trustedCertEntry, Certificate fingerprint (MD5):
> > 80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB
>
> This is not sufficient, you need to have at least a key for the server
> to use. You can generate this using keytool -genkey.
>
> > My ftpd.xml has the following configuration:
> >
> > <listeners>
> > <nio-listener name="default" port="30021"
> > implicit-ssl="true">
> > <ssl protocol="SSL"
> > client-authentication="WANT">
>
> Noramlly, you do not need these attributes.
>
> > <keystore file="conf/keystore.jks"
> > password="password" key-alias="xfer" algorithm="IbmX509" />
>
> You do not need the key-alias attribute if the keystore only contains
> your key. I'm not sure if you need the algorithm, but I would not
> think so.
>
> > <truststore file="conf/keystore.jks"
> > password="password" algorithm="IbmX509" />
>
> Again, algorithm might not be needed.
>
> That should be it, let us know if it helps or not. We can probably
> improve our error logging in this area, I'll have a look at that after
> 1.0.
>
> /niklas
>
>
>
> -----------------------------------------
> Use of email is inherently insecure. Confidential information,
> including account information, and personally identifiable
> information, should not be transmitted via email, or email attachment.
> In no event shall Citizens or any of its affiliates accept any
> responsibility for the loss, use or misuse of any information
> including confidential information, which is sent to Citizens or its
> affiliates via email, or email attachment. Citizens does not guarantee
> the accuracy of any email or email attachment, that an email will be
> received by Citizens or that Citizens will respond to any email.
>
> This email message is confidential and/or privileged. It is to be used
> by the intended recipient only. Use of the information contained in
> this email by anyone other than the intended recipient is strictly
> prohibited. If you have received this message in error, please notify
> the sender immediately and promptly destroy any record of this email.
>
>
-----------------------------------------
Use of email is inherently insecure. Confidential information,
including account information, and personally identifiable
information, should not be transmitted via email, or email
attachment. In no event shall Citizens or any of its affiliates
accept any responsibility for the loss, use or misuse of any
information including confidential information, which is sent to
Citizens or its affiliates via email, or email attachment. Citizens
does not guarantee the accuracy of any email or email attachment,
that an email will be received by Citizens or that Citizens will
respond to any email.
This email message is confidential and/or privileged. It is to be
used by the intended recipient only. Use of the information
contained in this email by anyone other than the intended recipient
is strictly prohibited. If you have received this message in error,
please notify the sender immediately and promptly destroy any
record of this email.
Re: SSL setup problems...
Posted by Sai Pullabhotla <sa...@jmethods.com>.
This is an issue with IBM's JVM where they decided to change things around
in Java 1.5. The thing that they changed is the implementation of
getInstance() method in SSLContext class.
The SunJVMs work fine with SSL/TLS peer when you initialized the SSLContext
with SSLContext.getInstance("TLS"). The same used to work fine in IBM's JVM
in version 1.4. However, they decided not to do so in 1.5. When I spoke to
their Support, they said that they are not going to change it back bacause
they changed it for a reason in the first place.
With the newer IBM's JVM, the call to SSLContext.getInstance("TLS") only
works if the other end is actually using TLS. If the other end uses SSL,
IBM's JSSE thows a handshake exception.
If you want your application to connect to either SSL or TLS, you need to
initialize the SSLContext by passing "SSL_TLS" as the protocol.
More information on this can be found on the IBM's Java web site (I found it
a long time ago, hope you can still find it).
The answer to your question is, there won't be any 'real' issues specifying
"SSL_TLS" other than the fact that you are supporting both SSL and TLS for
your FTP clients. Your server might be vulnerable to all known issues in SSL
v3, if any.
Sai Pullabhotla
Phone: (402) 408-5753
Fax: (402) 408-6861
www.jMethods.com
On Tue, Feb 3, 2009 at 10:43 AM, West, John C
<Jo...@citizensbank.com>wrote:
>
>
> So everything is not fine after all.
>
> After dancing around a load of internal networking issues, I'm now
> getting:
> javax.net.ssl.SSLHandshakeException: Client requested protocol SSLv3 not
> enabled or not supported
>
> on the data connection (PASV). Here's my listener config:
> <listeners>
> <nio-listener name="default" port="30021"
> implicit-ssl="false">
> <ssl>
> <keystore file="conf/keystore.jks"
> password="password" key-alias="key" algorithm="IbmX509" />
> <truststore file="conf/keystore.jks"
> password="password" algorithm="IbmX509" />
> </ssl>
> <data-connection idle-timeout="60">
> <active local-port="40021" />
> <passive ports="40021-40049" />
> </data-connection>
>
> </nio-listener>
> </listeners>
>
>
> As you can see, I'm not specifying SSL or TLS. The control connection
> works fine (over TLS) and then the client tries to open the data
> connection using SSLv3 and that's when I get the error. I wrote a quick
> app to list out the protocols supported by the jre I'm using and I got
> [SSLv3, TLS, TLSv1, SSL, SSL_TLS] so SSLv3 is available.
>
> While the client team tries to figure out how to use TLS for both, I
> thought I'd do some investigating. Is leaving the protocol out of the
> ssl tag the same as specifying SSL_TLS? Would there be any issues mixing
> TLS/SSL?
>
>
>
>
> -----Original Message-----
> From: West, John C
> Sent: Thursday, January 29, 2009 10:39 AM
> To: ftpserver-users@mina.apache.org
> Subject: RE: SSL setup problems...
>
>
> That's what I thought, but he was insistent that the cert is all that's
> required.
>
> I generated a new key and installed it, but it still didn't work. It
> turned out that the subsequent issue was caused by the client not
> playing well with implicit-ssl=true. I changed that and everything works
> fine now.
>
> Thanks for your help.
>
>
>
> -----Original Message-----
> From: Niklas Gustavsson [mailto:niklas@protocol7.com]
> Sent: Monday, January 26, 2009 4:43 PM
> To: ftpserver-dev@incubator.apache.org
> Subject: Re: SSL setup problems...
>
> On Mon, Jan 26, 2009 at 10:26 PM, West, John C
> <Jo...@citizensbank.com> wrote:
> > I have a keystore (conf/keystore.jks) with one certificate:
> > % keytool -list -keystore conf/keystore.jks Enter keystore password:
> > password
> >
> > Keystore type: jks
> > Keystore provider: IBMJCE
> >
> > Your keystore contains 1 entry
> >
> > xfer, Jan 26, 2009, trustedCertEntry,
> > Certificate fingerprint (MD5):
> > 80:40:2D:97:25:20:AD:50:BE:9D:06:CA:B0:77:CA:EB
>
> This is not sufficient, you need to have at least a key for the server
> to use. You can generate this using keytool -genkey.
>
> > My ftpd.xml has the following configuration:
> >
> > <listeners>
> > <nio-listener name="default" port="30021"
> > implicit-ssl="true">
> > <ssl protocol="SSL"
> > client-authentication="WANT">
>
> Noramlly, you do not need these attributes.
>
> > <keystore file="conf/keystore.jks"
> > password="password" key-alias="xfer" algorithm="IbmX509" />
>
> You do not need the key-alias attribute if the keystore only contains
> your key. I'm not sure if you need the algorithm, but I would not think
> so.
>
> > <truststore file="conf/keystore.jks"
> > password="password" algorithm="IbmX509" />
>
> Again, algorithm might not be needed.
>
> That should be it, let us know if it helps or not. We can probably
> improve our error logging in this area, I'll have a look at that after
> 1.0.
>
> /niklas
>
>
>
> -----------------------------------------
> Use of email is inherently insecure. Confidential information,
> including account information, and personally identifiable
> information, should not be transmitted via email, or email
> attachment. In no event shall Citizens or any of its affiliates
> accept any responsibility for the loss, use or misuse of any
> information including confidential information, which is sent to
> Citizens or its affiliates via email, or email attachment. Citizens
> does not guarantee the accuracy of any email or email attachment,
> that an email will be received by Citizens or that Citizens will
> respond to any email.
>
> This email message is confidential and/or privileged. It is to be
> used by the intended recipient only. Use of the information
> contained in this email by anyone other than the intended recipient
> is strictly prohibited. If you have received this message in error,
> please notify the sender immediately and promptly destroy any
> record of this email.
>
>