You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Travis Gebhardt <tr...@kayak.com> on 2008/02/27 23:39:56 UTC
upgrading from XFire - SSL handshake errors
Have the default cipher suites changed between XFire and CXF?
The reason I ask is that I am in the process of upgrading a XFire client to
CXF. The XFire client successfully uses a SOAP service over HTTPS. I didn't
do anything particular to get XFire working over HTTPS so presumably the
default cipher suites were used.
My first attempt at connecting to the same endpoint via my new CXF client
resulted in the following SSL handshake_failure:
INFO: The cipher suites have been set to SSL_RSA_WITH_DES_CBC_SHA,
SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5.
%% No cached client session
*** ClientHello, SSLv3
RandomCookie: GMT: 1187298740 bytes = { 113, 45, 193, 158, 214, 231, 11,
225, 197, 38, 3, 179, 175, 26, 25, 234, 108, 241, 155, 106, 191, 62, 221,
65, 209, 8, 182, 48 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5, SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5]
Compression Methods: { 0 }
***
WRITE: SSLv3 Handshake, length = 79
WRITE: SSLv2 client hello message, length = 101
READ: SSLv3 Alert, length = 2
RECV TLSv1 ALERT: fatal, handshake_failure
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
Feb 27, 2008 2:49:08 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter.
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:136)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:76)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage(SoapOutInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:208)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy48.localAuthenticationQuery(Unknown Source) ...
Caused by: javax.xml.stream.XMLStreamException
at
com.sun.xml.stream.writers.XMLStreamWriterImpl.writeStartElement(XMLStreamWriterImpl.java:1210)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnvelopeStart(SoapOutInterceptor.java:95)
... 16 more
After googling around for "SSLv3 Alert, length = 2" I found that this can
occur when the server rejects the cipher suites given in the ClientHello
message. By running the working XFire client with
"-Djavax.net.debug=ssl,handshake" enabled I learned that the server was
choosing SSL_RSA_WITH_3DES_EDE_CBC_SHA as the cipher suite. Sure enough
this cipher suite isn't in the default cipher suites thay my CXF client was
picking up (list is above). Adding this to my CXF client resolved the
handshake issue:
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.getCipherSuites().add("SSL_RSA_WITH_3DES_EDE_CBC_SHA");
conduit.setTlsClientParameters(tlsParams);
I'm all set now but this got me thinking about how my upgrade could have
been made much smoother had the default cipher suites remained the same. But
perhaps there is a good reason why they differ?
thanks,
-Travis
--
View this message in context: http://www.nabble.com/upgrading-from-XFire---SSL-handshake-errors-tp15725238p15725238.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: upgrading from XFire - SSL handshake errors
Posted by Travis Gebhardt <tr...@kayak.com>.
Thanks Donal.
I've entered http://issues.apache.org/jira/browse/CXF-1456 CXF-1456 on
this issue.
-Travis
Arundel, Donal wrote:
>
> You are right, Its unfortunate that the ciphersuite "3DES_EDE_CBC_SHA"
> isn't enabled by default since this is a strong and commonly used
> ciphersuite.
> I suspect it is an oversight.
>
> Do you want to raise a JIRA on this? (should be easily fixed)
> I'll raise one if you want, but thought it would be nice to have the
> original reporter.
> ...
>
--
View this message in context: http://www.nabble.com/upgrading-from-XFire---SSL-handshake-errors-tp15725238p15738664.html
Sent from the cxf-user mailing list archive at Nabble.com.
RE: upgrading from XFire - SSL handshake errors
Posted by "Arundel, Donal" <do...@iona.com>.
You are right, Its unfortunate that the ciphersuite "3DES_EDE_CBC_SHA"
isn't enabled by default since this is a strong and commonly used
ciphersuite.
I suspect it is an oversight.
Do you want to raise a JIRA on this? (should be easily fixed)
I'll raise one if you want, but thought it would be nice to have the
original reporter.
A sensible default for the list of supported ciphers would be :
- All supported full strength ciphers are present.
By full strength I mean non-export crippled, non-null encryption
- Anon Diffie-Hellman ciphersuites should be disabled by default
(subject to man in the middle attacks)
- Null encryption variant ciphersuites should also be disabled by
default.
- I'm not sure that all of the RSA / DHE_DSS and Kerberos ones should be
present by default. It seems to me bad practice to have these in your
config if your application doesn't have the required credentials and
trust info to support them (e.g. via DSS certificates etc).
I would need to track down the actual log message and see if it is just
referring to the base set of ciphersuites available to the toolkit as
opposed to the set of ciphersuites that have actively been applied to
the endpoint. (A slightly more explicit log message would help).
i.e. I would worry that at some point a new version of CXF could throw
an error if you specified certain public key algorithm specific
ciphersuites that you didn't have the credentials/trust info to support.
Cheers,
Donal
-----Original Message-----
From: Travis Gebhardt [mailto:travis@kayak.com]
Sent: 27 February 2008 22:40
To: cxf-user@incubator.apache.org
Subject: upgrading from XFire - SSL handshake errors
Have the default cipher suites changed between XFire and CXF?
The reason I ask is that I am in the process of upgrading a XFire client
to
CXF. The XFire client successfully uses a SOAP service over HTTPS. I
didn't
do anything particular to get XFire working over HTTPS so presumably the
default cipher suites were used.
My first attempt at connecting to the same endpoint via my new CXF
client
resulted in the following SSL handshake_failure:
INFO: The cipher suites have been set to SSL_RSA_WITH_DES_CBC_SHA,
SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA,
SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5.
%% No cached client session
*** ClientHello, SSLv3
RandomCookie: GMT: 1187298740 bytes = { 113, 45, 193, 158, 214, 231,
11,
225, 197, 38, 3, 179, 175, 26, 25, 234, 108, 241, 155, 106, 191, 62,
221,
65, 209, 8, 182, 48 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA,
SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5,
SSL_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA,
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_WITH_NULL_MD5,
SSL_RSA_WITH_NULL_SHA, SSL_DH_anon_WITH_DES_CBC_SHA,
SSL_DH_anon_EXPORT_WITH_RC4_40_MD5,
SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA,
TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_EXPORT_WITH_RC4_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5]
Compression Methods: { 0 }
***
WRITE: SSLv3 Handshake, length = 79
WRITE: SSLv2 client hello message, length = 101
READ: SSLv3 Alert, length = 2
RECV TLSv1 ALERT: fatal, handshake_failure
called closeSocket()
handling exception: javax.net.ssl.SSLHandshakeException: Received fatal
alert: handshake_failure
Feb 27, 2008 2:49:08 PM org.apache.cxf.phase.PhaseInterceptorChain
doIntercept
INFO: Interceptor has thrown exception, unwinding now
org.apache.cxf.binding.soap.SoapFault: Error writing to XMLStreamWriter.
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnve
lopeStart(SoapOutInterceptor.java:136)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage
(SoapOutInterceptor.java:76)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.handleMessage
(SoapOutInterceptor.java:57)
at
org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorC
hain.java:208)
at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:276)
at
org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:222)
at
org.apache.cxf.frontend.ClientProxy.invokeSync(ClientProxy.java:73)
at
org.apache.cxf.jaxws.JaxWsClientProxy.invoke(JaxWsClientProxy.java:135)
at $Proxy48.localAuthenticationQuery(Unknown Source) ...
Caused by: javax.xml.stream.XMLStreamException
at
com.sun.xml.stream.writers.XMLStreamWriterImpl.writeStartElement(XMLStre
amWriterImpl.java:1210)
at
org.apache.cxf.binding.soap.interceptor.SoapOutInterceptor.writeSoapEnve
lopeStart(SoapOutInterceptor.java:95)
... 16 more
After googling around for "SSLv3 Alert, length = 2" I found that this
can
occur when the server rejects the cipher suites given in the ClientHello
message. By running the working XFire client with
"-Djavax.net.debug=ssl,handshake" enabled I learned that the server was
choosing SSL_RSA_WITH_3DES_EDE_CBC_SHA as the cipher suite. Sure enough
this cipher suite isn't in the default cipher suites thay my CXF client
was
picking up (list is above). Adding this to my CXF client resolved the
handshake issue:
TLSClientParameters tlsParams = new TLSClientParameters();
tlsParams.getCipherSuites().add("SSL_RSA_WITH_3DES_EDE_CBC_SHA");
conduit.setTlsClientParameters(tlsParams);
I'm all set now but this got me thinking about how my upgrade could have
been made much smoother had the default cipher suites remained the same.
But
perhaps there is a good reason why they differ?
thanks,
-Travis
--
View this message in context:
http://www.nabble.com/upgrading-from-XFire---SSL-handshake-errors-tp1572
5238p15725238.html
Sent from the cxf-user mailing list archive at Nabble.com.
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland