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 John Hartnup <jo...@gmail.com> on 2011/01/26 16:44:10 UTC
No common ciphersuite
I'm running ftpserver on J2SE 1.5 on Windows, and trying to connect to it
using the ftp-ssl client on Debian Linux.
On the server side I have:
<ssl protocol="TLS" client-authentication="NONE" >
<keystore file="test.jks" password="password" />
</ssl>
On the client side I have:
ftp -z certrequired -z cipher-ALL -z secure -z cert=client.pem -z
key=client.pem
The connection fails, logging:
Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
at
com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Handshaker.java:997)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:459)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1058)
at
com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1030)
at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:411)
at
org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:502)
I believe the client is OK -- it works with other servers.
If I specify enabled-ciphersuites in the ssl element of the server config, I
find that many of the ciphersuites listed here -
http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#AppA
-
cause the server to report an unavailable ciphersuite. I have not found a
ciphersuite I can use which satisfies the client, even basic ones such as
SSL_RSA_EXPORT_WITH_RC4_40_MD5
Any ideas?
Thanks,
John
--
"There is no way to peace; peace is the way"
Re: No common ciphersuite
Posted by John Hartnup <jo...@gmail.com>.
I suspected as much. Thanks for the willingness!
On 27 January 2011 11:29, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Thu, Jan 27, 2011 at 11:49 AM, John Hartnup <jo...@gmail.com>
> wrote:
> > The error message is misleading; worth a bug report? For ftpserver or for
> > MINA?
> > Or is it something that the Java security API prevents fixing?
>
> I'm afraid this error comes from the JRE and there is not much we can
> do in MINA or FtpServer. Unless someone sees a way in which case we're
> happy to look into that :-)
>
> /niklas
>
--
"There is no way to peace; peace is the way"
Re: No common ciphersuite
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Thu, Jan 27, 2011 at 11:49 AM, John Hartnup <jo...@gmail.com> wrote:
> The error message is misleading; worth a bug report? For ftpserver or for
> MINA?
> Or is it something that the Java security API prevents fixing?
I'm afraid this error comes from the JRE and there is not much we can
do in MINA or FtpServer. Unless someone sees a way in which case we're
happy to look into that :-)
/niklas
Re: No common ciphersuite
Posted by John Hartnup <jo...@gmail.com>.
Thanks for that Brad -- it was some kind of problem with the server
certificate JKS file.
The error message is misleading; worth a bug report? For ftpserver or for
MINA?
Or is it something that the Java security API prevents fixing?
On 26 January 2011 23:17, Brad McEvoy <br...@bradmcevoy.com> wrote:
>
> I had the same problem recently (not with apache ftp, but with another
> server, but i think its all the same under the hood), and of course the
> problem wasnt anything to do with missing cipher suites.
>
> Can't remember exactly what it was but it was just a config error. It
> caused an exception deep down in the bowels of java ssl which was swallowed
> with being logged. Once i saw what that exception was it was immediately
> obvious what i had done wrong.
>
> I eventually found the problem with java debugging stepping through the ssl
> initialisation.
>
>
> On 27/01/11 11:47, John Hartnup wrote:
>
>> This is very strange. I've not been able to reproduce my one successful
>> run.
>>
>> I definitely have *no* enabled-ciphersuites attribute right now, so it
>> should support a healthy set of ciphersuites.
>>
>> Without the "-z cipher" parameter, openssl's hello requests the same 26
>> ciphersuites.
>>
>> Is there a way to get ftpserver to list the ciphersuites it supports?
>>
>> I've tried on a few of the JVMs that I have on my box.
>>
>> On 26 January 2011 18:30, Niklas Gustavsson<ni...@protocol7.com> wrote:
>>
>> On Wed, Jan 26, 2011 at 6:09 PM, John Hartnup<jo...@gmail.com>
>>> wrote:
>>>
>>>> If I don't specify a ciphersuite, according to the documentation, the
>>>>
>>> server
>>>
>>>> should accept every ciphersuite available to Java. Yet it is the Java
>>>>
>>> side
>>>
>>>> that is reporting "no matching ciphersuite", and sending the SSL alert
>>>> in
>>>> response to the client hello.
>>>>
>>> That's correct, if no cipher suites are listed, all will be active.
>>> Make sure you do not have the attribute with an empty string, that
>>> will cause all cipher suites to be disabled. Also, you do not need to
>>> specify client-authentication="NONE" as that's the default value.
>>>
>>> On the client, does it make any difference to remove the use of -z
>>> cipher-ALL ?
>>>
>>> /niklas
>>>
>>>
>>
>>
>
--
"There is no way to peace; peace is the way"
Re: No common ciphersuite
Posted by Brad McEvoy <br...@bradmcevoy.com>.
I had the same problem recently (not with apache ftp, but with another
server, but i think its all the same under the hood), and of course the
problem wasnt anything to do with missing cipher suites.
Can't remember exactly what it was but it was just a config error. It
caused an exception deep down in the bowels of java ssl which was
swallowed with being logged. Once i saw what that exception was it was
immediately obvious what i had done wrong.
I eventually found the problem with java debugging stepping through the
ssl initialisation.
On 27/01/11 11:47, John Hartnup wrote:
> This is very strange. I've not been able to reproduce my one successful run.
>
> I definitely have *no* enabled-ciphersuites attribute right now, so it
> should support a healthy set of ciphersuites.
>
> Without the "-z cipher" parameter, openssl's hello requests the same 26
> ciphersuites.
>
> Is there a way to get ftpserver to list the ciphersuites it supports?
>
> I've tried on a few of the JVMs that I have on my box.
>
> On 26 January 2011 18:30, Niklas Gustavsson<ni...@protocol7.com> wrote:
>
>> On Wed, Jan 26, 2011 at 6:09 PM, John Hartnup<jo...@gmail.com>
>> wrote:
>>> If I don't specify a ciphersuite, according to the documentation, the
>> server
>>> should accept every ciphersuite available to Java. Yet it is the Java
>> side
>>> that is reporting "no matching ciphersuite", and sending the SSL alert in
>>> response to the client hello.
>> That's correct, if no cipher suites are listed, all will be active.
>> Make sure you do not have the attribute with an empty string, that
>> will cause all cipher suites to be disabled. Also, you do not need to
>> specify client-authentication="NONE" as that's the default value.
>>
>> On the client, does it make any difference to remove the use of -z
>> cipher-ALL ?
>>
>> /niklas
>>
>
>
Re: No common ciphersuite
Posted by John Hartnup <jo...@gmail.com>.
This is very strange. I've not been able to reproduce my one successful run.
I definitely have *no* enabled-ciphersuites attribute right now, so it
should support a healthy set of ciphersuites.
Without the "-z cipher" parameter, openssl's hello requests the same 26
ciphersuites.
Is there a way to get ftpserver to list the ciphersuites it supports?
I've tried on a few of the JVMs that I have on my box.
On 26 January 2011 18:30, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Wed, Jan 26, 2011 at 6:09 PM, John Hartnup <jo...@gmail.com>
> wrote:
> > If I don't specify a ciphersuite, according to the documentation, the
> server
> > should accept every ciphersuite available to Java. Yet it is the Java
> side
> > that is reporting "no matching ciphersuite", and sending the SSL alert in
> > response to the client hello.
>
> That's correct, if no cipher suites are listed, all will be active.
> Make sure you do not have the attribute with an empty string, that
> will cause all cipher suites to be disabled. Also, you do not need to
> specify client-authentication="NONE" as that's the default value.
>
> On the client, does it make any difference to remove the use of -z
> cipher-ALL ?
>
> /niklas
>
--
"There is no way to peace; peace is the way"
Re: No common ciphersuite
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Wed, Jan 26, 2011 at 6:09 PM, John Hartnup <jo...@gmail.com> wrote:
> If I don't specify a ciphersuite, according to the documentation, the server
> should accept every ciphersuite available to Java. Yet it is the Java side
> that is reporting "no matching ciphersuite", and sending the SSL alert in
> response to the client hello.
That's correct, if no cipher suites are listed, all will be active.
Make sure you do not have the attribute with an empty string, that
will cause all cipher suites to be disabled. Also, you do not need to
specify client-authentication="NONE" as that's the default value.
On the client, does it make any difference to remove the use of -z cipher-ALL ?
/niklas
Re: No common ciphersuite
Posted by John Hartnup <jo...@gmail.com>.
Update: I traced the session with Wireshark.
The SSL client hello from openssl lists 26 ciphersuites (which I can't work
out how to copy/paste from Wireshark!)
When I put the first of these, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, into the
enabled-ciphersuites attribute, the session works.
If I don't specify a ciphersuite, according to the documentation, the server
should accept every ciphersuite available to Java. Yet it is the Java side
that is reporting "no matching ciphersuite", and sending the SSL alert in
response to the client hello.
I don't want to tune the server configuration to this specific client,
because I don't have control over what clients my users will have.
I'd welcome any comments anyone has.
On 26 January 2011 15:44, John Hartnup <jo...@gmail.com> wrote:
> I'm running ftpserver on J2SE 1.5 on Windows, and trying to connect to it
> using the ftp-ssl client on Debian Linux.
>
> On the server side I have:
> <ssl protocol="TLS" client-authentication="NONE" >
> <keystore file="test.jks" password="password" />
> </ssl>
>
> On the client side I have:
> ftp -z certrequired -z cipher-ALL -z secure -z cert=client.pem -z
> key=client.pem
>
> The connection fails, logging:
> Caused by: javax.net.ssl.SSLHandshakeException: no cipher suites in common
> at
> com.sun.net.ssl.internal.ssl.Handshaker.checkThrown(Handshaker.java:997)
> at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.checkTaskThrown(SSLEngineImpl.java:459)
> at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.writeAppRecord(SSLEngineImpl.java:1058)
> at
> com.sun.net.ssl.internal.ssl.SSLEngineImpl.wrap(SSLEngineImpl.java:1030)
> at javax.net.ssl.SSLEngine.wrap(SSLEngine.java:411)
> at
> org.apache.mina.filter.ssl.SslHandler.handshake(SslHandler.java:502)
>
> I believe the client is OK -- it works with other servers.
>
> If I specify enabled-ciphersuites in the ssl element of the server config,
> I find that many of the ciphersuites listed here -
> http://download.oracle.com/javase/1.5.0/docs/guide/security/jsse/JSSERefGuide.html#AppA -
> cause the server to report an unavailable ciphersuite. I have not found a
> ciphersuite I can use which satisfies the client, even basic ones such as
> SSL_RSA_EXPORT_WITH_RC4_40_MD5
>
> Any ideas?
>
> Thanks,
> John
> --
> "There is no way to peace; peace is the way"
>
--
"There is no way to peace; peace is the way"