You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@activemq.apache.org by Jason Dillon <ja...@planet57.com> on 2011/12/30 10:46:16 UTC
nio+ssl w/programatic {key|trust}store configuration
Has anyone tried using the nio+ssl transport w/programatic keystore and trust store configuration similar to using SslBrokerService.addSslConnector(String, KeyManager[], TrustManager[], SecureRandom)?
I tried configuring the transport similarly in an extension:
<snip>
public class ExtBrokerService
extends SslBrokerService
{
@Override
protected TransportServer createSslTransportServer(final URI brokerURI, final KeyManager[] km, final TrustManager[] tm, final SecureRandom random)
throws IOException, KeyManagementException
{
if (brokerURI.getScheme().equals("ssl")) { //NON-NLS
SslTransportFactory transportFactory = new SslTransportFactory();
SslContext ctx = new SslContext(km, tm, random);
SslContext.setCurrentSslContext(ctx);
try {
return transportFactory.doBind(brokerURI);
}
finally {
SslContext.setCurrentSslContext(null);
}
}
else if (brokerURI.getScheme().equals("nio+ssl")) { //NON-NLS
SslContext ctx = new SslContext(km, tm, random);
SslContext.setCurrentSslContext(ctx);
NIOSSLTransportFactory transportFactory = new NIOSSLTransportFactory();
try {
return transportFactory.doBind(brokerURI);
}
finally {
SslContext.setCurrentSslContext(null);
}
}
else {
return TransportFactory.bind(this, brokerURI);
}
}
}
</snip>
And then configuring with:
<snip>
ExtBrokerService brokerService = new ExtBrokerService();
TransportConnector connector = brokerService.addSslConnector("nio+ssl://0.0.0.0:0?needClientAuth=true",
keyStoreManager.getKeyManagers(), keyStoreManager.getTrustManagers(), new SecureRandom());
</snip>
This does appear to start up the transport using nio+ssl. I've confirmed that the overridden createSslTransportServer() is getting called and is using the "nio+ssl" logic branch.
Its unclear if the needClientAuth bits are getting configured however, since its difficult to inspect vs using the ssl transport via ((SslTransportServer)connector.getServer()).getNeedClientAuth().
Testing with a ssl:// client connection configured with the appropriate {key|trust}stores fails, complaining about "no cipher suites in common". Some of the ssl debug output shows:
<snip>
...
ActiveMQ Task-1, READ: SSL v2, contentType = Handshake, translated length = 113
*** ClientHello, TLSv1
RandomCookie: GMT: 1308393557 bytes = { 81, 129, 30, 234, 206, 134, 210, 218, 170, 130, 85, 15, 37, 247, 89, 189, 135, 213, 205, 15, 19, 38, 77, 90, 224, 246, 175, 61 }
Session ID: {}
Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
Compression Methods: { 0 }
***
ActiveMQ Task-2, fatal error: 40: no cipher suites in common
javax.net.ssl.SSLHandshakeException: no cipher suites in common
ActiveMQ Task-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
ActiveMQ Task-2, WRITE: TLSv1 Alert, length = 2
ActiveMQ Task-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common
...
</snip>
Running the *exact same test* changing only the brokers transport scheme from "nio+ssl" to "ssl" and the ssl connection is established correctly and the test behaves as expected wrt clientAuth, etc.
I was digging around a little, and I'm not really sure if this is correct... but it does not look like the nio+ssl transport server is getting the ssl serversocketfactory instead which NIOSSLTransportFActory.createSocketFactory() should be returning. Actually when running the tests above I don't see that method called at all. I also dropped a breakpoint at NIOSSLTransportFactory:51
( https://skitch.com/jasondillon/gw6ft/nio-ssl-w-programatic-key-trust-store-configuration )
And then started to inspect the variables in scope, and it looks like the serverSocketFactory instance given is from NIOTransportFactory.createServerSocketFactory() return:
( https://skitch.com/jasondillon/gw6fu/nio-ssl-w-programatic-key-trust-store-configuration )
SSL makes my head want to explode some times. The NIO transport code and the SSL version of it is a little more complex to follow how its supposed to work vs. the SSL layer on-top of the TCP transport.
Anyways, I'm not sure if the socket factory is an issue here or not, but it could be related? I'm also guessing that programatic access using nio+ssl hasn't been used that muck since the SslBrokerFactory has not been updated to deal with setting the SslContext for nio+ssl scheme (as shown in ExtBrokerService above)?
The NIOSSLTransportBrokerTest appears to pass:
<snip>
-------------------------------------------------------
T E S T S
-------------------------------------------------------
Running org.apache.activemq.transport.nio.NIOSSLTransportBrokerTest
Tests run: 129, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 261.187 sec
</snip>
... so I'm guessing that configuring the trust/keystore bits work okay when configuration them globally via javax.net.ssl.* properties?
* * *
Does anyone have any idea what might be going on here which would cause "no cipher suites in common" errors when using "nio+ssl" when "ssl" works just fine?
Thanks,
--jason
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by paul woods <pa...@geolang.com>.
Very old thread - but just in case someone comes accross this!
SSLContext ctx = SSLContext.getInstance("TLS"); // for nio
ctx.init(getKeyManager(), getTrustManager(), new SecureRandom());
SSLContext.setDefault(ctx);
Note javax.net.ssl.SSLContext and NOT org.apache.activemq.broker.SslContext
--
Sent from: http://activemq.2283324.n4.nabble.com/ActiveMQ-User-f2341805.html
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Jason Dillon <ja...@planet57.com>.
On Jan 5, 2012, at 2:58 AM, Dejan Bosanac wrote:
>> Why then do the NIO[SSL]* bits even have methods with *SocketFactory bits,
>> is this due to extending the TCP bits?
>
> It's used on the client side to create socket.
I thought the client-side was expected to use the regular ssl transport?
> What is the NIO version of the SslSocketFactory muck? (I know jack about
>> nio, only that it exists and uses buffers and channels).
>>
> There is no one. That's the whole problem as you need to do whole
> hand-shaking thing in your app,
Wonderful.
--jason
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Dejan Bosanac <de...@nighttale.net>.
>
>
> Why then do the NIO[SSL]* bits even have methods with *SocketFactory bits,
> is this due to extending the TCP bits?
>
It's used on the client side to create socket.
>
> What is the NIO version of the SslSocketFactory muck? (I know jack about
> nio, only that it exists and uses buffers and channels).
>
>
There is no one. That's the whole problem as you need to do whole
hand-shaking thing in your app,
>
> > We should provide the proper ssl context to the NIOSSLTransport
> > using setSslContext() method, so you might start with checking if the
> > correct context is being passed there.
>
> I'll look into it more when I have some time.
>
>
Thanks.
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Jason Dillon <ja...@planet57.com>.
On Jan 4, 2012, at 5:41 AM, Dejan Bosanac wrote:
> nio+ssl should work exactly the same as the plain ssl transport, so this
> SslBrokerService enhancement you're working is totally valid and we should
> have it.
Okay I think I can make a simple test to show working ssl and non-working nio+ssl then.
> The reason why socket factory isn't used in nio case is because it isn't
> used by the java nio ssl API (if you hate ssl you'll hate nio+ssl even more
> :)
Why then do the NIO[SSL]* bits even have methods with *SocketFactory bits, is this due to extending the TCP bits?
What is the NIO version of the SslSocketFactory muck? (I know jack about nio, only that it exists and uses buffers and channels).
> We should provide the proper ssl context to the NIOSSLTransport
> using setSslContext() method, so you might start with checking if the
> correct context is being passed there.
I'll look into it more when I have some time.
> I'm looking forward to your further work in this area.
Thanks for the detail :-)
--jason
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Dejan Bosanac <de...@nighttale.net>.
nio+ssl should work exactly the same as the plain ssl transport, so this
SslBrokerService enhancement you're working is totally valid and we should
have it.
The reason why socket factory isn't used in nio case is because it isn't
used by the java nio ssl API (if you hate ssl you'll hate nio+ssl even more
:)
We should provide the proper ssl context to the NIOSSLTransport
using setSslContext() method, so you might start with checking if the
correct context is being passed there.
I'm looking forward to your further work in this area.
Regards
--
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Wed, Jan 4, 2012 at 12:41 AM, Jason Dillon <ja...@planet57.com> wrote:
> On Jan 3, 2012, at 3:14 AM, Dejan Bosanac wrote:
> > Hi Jason,
> >
> > maybe the best way to start is to create "programatically configured"
> version of NIOSSLTransportBrokerTest and attach it to Jira.
>
> Depends, is the ExtBrokerService.createSsslTransportServer() example below
> the correct/expect method to configure the SslContext for use by the
> nio+ssl transport?
>
> If its not... then I have no idea how to configure the ssl details for
> nio+ssl and thus it would be pointless to create a test. If it is then I
> can certainly abstract out my local test into something consumable by the
> public.
>
> I did however ask a few questions in this email... which would be very
> helpful to have answers to in order to create an appropriate test.
>
> Is the author of the nio+ssl transport not around the help answer some of
> them?
>
> --jason
>
>
>
> > Regards
> > --
> > Dejan Bosanac - http://twitter.com/dejanb
> > -----------------
> > The experts in open source integration and messaging -
> http://fusesource.com
> > ActiveMQ in Action - http://www.manning.com/snyder/
> > Blog - http://www.nighttale.net
> >
> >
> > On Fri, Dec 30, 2011 at 10:46 AM, Jason Dillon <ja...@planet57.com>
> wrote:
> > Has anyone tried using the nio+ssl transport w/programatic keystore and
> trust store configuration similar to using
> SslBrokerService.addSslConnector(String, KeyManager[], TrustManager[],
> SecureRandom)?
> >
> > I tried configuring the transport similarly in an extension:
> >
> > <snip>
> > public class ExtBrokerService
> > extends SslBrokerService
> > {
> > @Override
> > protected TransportServer createSslTransportServer(final URI
> brokerURI, final KeyManager[] km, final TrustManager[] tm, final
> SecureRandom random)
> > throws IOException, KeyManagementException
> > {
> > if (brokerURI.getScheme().equals("ssl")) { //NON-NLS
> > SslTransportFactory transportFactory = new
> SslTransportFactory();
> > SslContext ctx = new SslContext(km, tm, random);
> > SslContext.setCurrentSslContext(ctx);
> > try {
> > return transportFactory.doBind(brokerURI);
> > }
> > finally {
> > SslContext.setCurrentSslContext(null);
> > }
> > }
> > else if (brokerURI.getScheme().equals("nio+ssl")) { //NON-NLS
> > SslContext ctx = new SslContext(km, tm, random);
> > SslContext.setCurrentSslContext(ctx);
> > NIOSSLTransportFactory transportFactory = new
> NIOSSLTransportFactory();
> > try {
> > return transportFactory.doBind(brokerURI);
> > }
> > finally {
> > SslContext.setCurrentSslContext(null);
> > }
> > }
> > else {
> > return TransportFactory.bind(this, brokerURI);
> > }
> > }
> > }
> > </snip>
> >
> > And then configuring with:
> >
> > <snip>
> > ExtBrokerService brokerService = new ExtBrokerService();
> > TransportConnector connector =
> brokerService.addSslConnector("nio+ssl://0.0.0.0:0?needClientAuth=true",
> > keyStoreManager.getKeyManagers(),
> keyStoreManager.getTrustManagers(), new SecureRandom());
> > </snip>
> >
> > This does appear to start up the transport using nio+ssl. I've
> confirmed that the overridden createSslTransportServer() is getting called
> and is using the "nio+ssl" logic branch.
> >
> > Its unclear if the needClientAuth bits are getting configured however,
> since its difficult to inspect vs using the ssl transport via
> ((SslTransportServer)connector.getServer()).getNeedClientAuth().
> >
> > Testing with a ssl:// client connection configured with the appropriate
> {key|trust}stores fails, complaining about "no cipher suites in common".
> Some of the ssl debug output shows:
> >
> > <snip>
> > ...
> > ActiveMQ Task-1, READ: SSL v2, contentType = Handshake, translated
> length = 113
> > *** ClientHello, TLSv1
> > RandomCookie: GMT: 1308393557 bytes = { 81, 129, 30, 234, 206, 134,
> 210, 218, 170, 130, 85, 15, 37, 247, 89, 189, 135, 213, 205, 15, 19, 38,
> 77, 90, 224, 246, 175, 61 }
> > Session ID: {}
> > Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> > Compression Methods: { 0 }
> > ***
> > ActiveMQ Task-2, fatal error: 40: no cipher suites in common
> > javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > ActiveMQ Task-2, SEND TLSv1 ALERT: fatal, description =
> handshake_failure
> > ActiveMQ Task-2, WRITE: TLSv1 Alert, length = 2
> > ActiveMQ Task-1, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> > ...
> > </snip>
> >
> > Running the *exact same test* changing only the brokers transport scheme
> from "nio+ssl" to "ssl" and the ssl connection is established correctly and
> the test behaves as expected wrt clientAuth, etc.
> >
> > I was digging around a little, and I'm not really sure if this is
> correct... but it does not look like the nio+ssl transport server is
> getting the ssl serversocketfactory instead which
> NIOSSLTransportFActory.createSocketFactory() should be returning. Actually
> when running the tests above I don't see that method called at all. I also
> dropped a breakpoint at NIOSSLTransportFactory:51
> >
> >
> >
> > (
> https://skitch.com/jasondillon/gw6ft/nio-ssl-w-programatic-key-trust-store-configuration)
> >
> > And then started to inspect the variables in scope, and it looks like
> the serverSocketFactory instance given is from
> NIOTransportFactory.createServerSocketFactory() return:
> >
> >
> >
> > (
> https://skitch.com/jasondillon/gw6fu/nio-ssl-w-programatic-key-trust-store-configuration)
> >
> > SSL makes my head want to explode some times. The NIO transport code
> and the SSL version of it is a little more complex to follow how its
> supposed to work vs. the SSL layer on-top of the TCP transport.
> >
> > Anyways, I'm not sure if the socket factory is an issue here or not, but
> it could be related? I'm also guessing that programatic access using
> nio+ssl hasn't been used that muck since the SslBrokerFactory has not been
> updated to deal with setting the SslContext for nio+ssl scheme (as shown in
> ExtBrokerService above)?
> >
> > The NIOSSLTransportBrokerTest appears to pass:
> >
> > <snip>
> > -------------------------------------------------------
> > T E S T S
> > -------------------------------------------------------
> >
> > Running org.apache.activemq.transport.nio.NIOSSLTransportBrokerTest
> > Tests run: 129, Failures: 0, Errors: 0, Skipped: 0, Time elapsed:
> 261.187 sec
> > </snip>
> >
> > ... so I'm guessing that configuring the trust/keystore bits work okay
> when configuration them globally via javax.net.ssl.* properties?
> >
> > * * *
> >
> > Does anyone have any idea what might be going on here which would cause
> "no cipher suites in common" errors when using "nio+ssl" when "ssl" works
> just fine?
> >
> > Thanks,
> >
> > --jason
> >
> >
> >
>
>
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Jason Dillon <ja...@planet57.com>.
On Jan 3, 2012, at 3:14 AM, Dejan Bosanac wrote:
> Hi Jason,
>
> maybe the best way to start is to create "programatically configured" version of NIOSSLTransportBrokerTest and attach it to Jira.
Depends, is the ExtBrokerService.createSsslTransportServer() example below the correct/expect method to configure the SslContext for use by the nio+ssl transport?
If its not... then I have no idea how to configure the ssl details for nio+ssl and thus it would be pointless to create a test. If it is then I can certainly abstract out my local test into something consumable by the public.
I did however ask a few questions in this email... which would be very helpful to have answers to in order to create an appropriate test.
Is the author of the nio+ssl transport not around the help answer some of them?
--jason
> Regards
> --
> Dejan Bosanac - http://twitter.com/dejanb
> -----------------
> The experts in open source integration and messaging - http://fusesource.com
> ActiveMQ in Action - http://www.manning.com/snyder/
> Blog - http://www.nighttale.net
>
>
> On Fri, Dec 30, 2011 at 10:46 AM, Jason Dillon <ja...@planet57.com> wrote:
> Has anyone tried using the nio+ssl transport w/programatic keystore and trust store configuration similar to using SslBrokerService.addSslConnector(String, KeyManager[], TrustManager[], SecureRandom)?
>
> I tried configuring the transport similarly in an extension:
>
> <snip>
> public class ExtBrokerService
> extends SslBrokerService
> {
> @Override
> protected TransportServer createSslTransportServer(final URI brokerURI, final KeyManager[] km, final TrustManager[] tm, final SecureRandom random)
> throws IOException, KeyManagementException
> {
> if (brokerURI.getScheme().equals("ssl")) { //NON-NLS
> SslTransportFactory transportFactory = new SslTransportFactory();
> SslContext ctx = new SslContext(km, tm, random);
> SslContext.setCurrentSslContext(ctx);
> try {
> return transportFactory.doBind(brokerURI);
> }
> finally {
> SslContext.setCurrentSslContext(null);
> }
> }
> else if (brokerURI.getScheme().equals("nio+ssl")) { //NON-NLS
> SslContext ctx = new SslContext(km, tm, random);
> SslContext.setCurrentSslContext(ctx);
> NIOSSLTransportFactory transportFactory = new NIOSSLTransportFactory();
> try {
> return transportFactory.doBind(brokerURI);
> }
> finally {
> SslContext.setCurrentSslContext(null);
> }
> }
> else {
> return TransportFactory.bind(this, brokerURI);
> }
> }
> }
> </snip>
>
> And then configuring with:
>
> <snip>
> ExtBrokerService brokerService = new ExtBrokerService();
> TransportConnector connector = brokerService.addSslConnector("nio+ssl://0.0.0.0:0?needClientAuth=true",
> keyStoreManager.getKeyManagers(), keyStoreManager.getTrustManagers(), new SecureRandom());
> </snip>
>
> This does appear to start up the transport using nio+ssl. I've confirmed that the overridden createSslTransportServer() is getting called and is using the "nio+ssl" logic branch.
>
> Its unclear if the needClientAuth bits are getting configured however, since its difficult to inspect vs using the ssl transport via ((SslTransportServer)connector.getServer()).getNeedClientAuth().
>
> Testing with a ssl:// client connection configured with the appropriate {key|trust}stores fails, complaining about "no cipher suites in common". Some of the ssl debug output shows:
>
> <snip>
> ...
> ActiveMQ Task-1, READ: SSL v2, contentType = Handshake, translated length = 113
> *** ClientHello, TLSv1
> RandomCookie: GMT: 1308393557 bytes = { 81, 129, 30, 234, 206, 134, 210, 218, 170, 130, 85, 15, 37, 247, 89, 189, 135, 213, 205, 15, 19, 38, 77, 90, 224, 246, 175, 61 }
> Session ID: {}
> Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> Compression Methods: { 0 }
> ***
> ActiveMQ Task-2, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> ActiveMQ Task-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
> ActiveMQ Task-2, WRITE: TLSv1 Alert, length = 2
> ActiveMQ Task-1, fatal: engine already closed. Rethrowing javax.net.ssl.SSLHandshakeException: no cipher suites in common
> ...
> </snip>
>
> Running the *exact same test* changing only the brokers transport scheme from "nio+ssl" to "ssl" and the ssl connection is established correctly and the test behaves as expected wrt clientAuth, etc.
>
> I was digging around a little, and I'm not really sure if this is correct... but it does not look like the nio+ssl transport server is getting the ssl serversocketfactory instead which NIOSSLTransportFActory.createSocketFactory() should be returning. Actually when running the tests above I don't see that method called at all. I also dropped a breakpoint at NIOSSLTransportFactory:51
>
>
>
> ( https://skitch.com/jasondillon/gw6ft/nio-ssl-w-programatic-key-trust-store-configuration )
>
> And then started to inspect the variables in scope, and it looks like the serverSocketFactory instance given is from NIOTransportFactory.createServerSocketFactory() return:
>
>
>
> ( https://skitch.com/jasondillon/gw6fu/nio-ssl-w-programatic-key-trust-store-configuration )
>
> SSL makes my head want to explode some times. The NIO transport code and the SSL version of it is a little more complex to follow how its supposed to work vs. the SSL layer on-top of the TCP transport.
>
> Anyways, I'm not sure if the socket factory is an issue here or not, but it could be related? I'm also guessing that programatic access using nio+ssl hasn't been used that muck since the SslBrokerFactory has not been updated to deal with setting the SslContext for nio+ssl scheme (as shown in ExtBrokerService above)?
>
> The NIOSSLTransportBrokerTest appears to pass:
>
> <snip>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
>
> Running org.apache.activemq.transport.nio.NIOSSLTransportBrokerTest
> Tests run: 129, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 261.187 sec
> </snip>
>
> ... so I'm guessing that configuring the trust/keystore bits work okay when configuration them globally via javax.net.ssl.* properties?
>
> * * *
>
> Does anyone have any idea what might be going on here which would cause "no cipher suites in common" errors when using "nio+ssl" when "ssl" works just fine?
>
> Thanks,
>
> --jason
>
>
>
Re: nio+ssl w/programatic {key|trust}store configuration
Posted by Dejan Bosanac <de...@nighttale.net>.
Hi Jason,
maybe the best way to start is to create "programatically configured"
version of NIOSSLTransportBrokerTest and attach it to Jira.
Regards
--
Dejan Bosanac - http://twitter.com/dejanb
-----------------
The experts in open source integration and messaging - http://fusesource.com
ActiveMQ in Action - http://www.manning.com/snyder/
Blog - http://www.nighttale.net
On Fri, Dec 30, 2011 at 10:46 AM, Jason Dillon <ja...@planet57.com> wrote:
> Has anyone tried using the nio+ssl transport w/programatic keystore and
> trust store configuration similar to using
> SslBrokerService.addSslConnector(String, KeyManager[], TrustManager[],
> SecureRandom)?
>
> I tried configuring the transport similarly in an extension:
>
> <snip>
> public class ExtBrokerService
> extends SslBrokerService
> {
> @Override
> protected TransportServer createSslTransportServer(final URI
> brokerURI, final KeyManager[] km, final TrustManager[] tm, final
> SecureRandom random)
> throws IOException, KeyManagementException
> {
> if (brokerURI.getScheme().equals("ssl")) { //NON-NLS
> SslTransportFactory transportFactory = new
> SslTransportFactory();
> SslContext ctx = new SslContext(km, tm, random);
> SslContext.setCurrentSslContext(ctx);
> try {
> return transportFactory.doBind(brokerURI);
> }
> finally {
> SslContext.setCurrentSslContext(null);
> }
> }
> else if (brokerURI.getScheme().equals("nio+ssl")) { //NON-NLS
> SslContext ctx = new SslContext(km, tm, random);
> SslContext.setCurrentSslContext(ctx);
> NIOSSLTransportFactory transportFactory = new
> NIOSSLTransportFactory();
> try {
> return transportFactory.doBind(brokerURI);
> }
> finally {
> SslContext.setCurrentSslContext(null);
> }
> }
> else {
> return TransportFactory.bind(this, brokerURI);
> }
> }
> }
> </snip>
>
> And then configuring with:
>
> <snip>
> ExtBrokerService brokerService = new ExtBrokerService();
> TransportConnector connector = brokerService.addSslConnector("
> nio+ssl://0.0.0.0:0?needClientAuth=true",
> keyStoreManager.getKeyManagers(),
> keyStoreManager.getTrustManagers(), new SecureRandom());
> </snip>
>
> This does appear to start up the transport using nio+ssl. I've confirmed
> that the overridden createSslTransportServer() is getting called and is
> using the "nio+ssl" logic branch.
>
> Its unclear if the needClientAuth bits are getting configured however,
> since its difficult to inspect vs using the ssl transport via
> ((SslTransportServer)connector.getServer()).getNeedClientAuth().
>
> Testing with a ssl:// client connection configured with the appropriate
> {key|trust}stores fails, complaining about "no cipher suites in common".
> Some of the ssl debug output shows:
>
> <snip>
> ...
> ActiveMQ Task-1, READ: SSL v2, contentType = Handshake, translated length
> = 113
> *** ClientHello, TLSv1
> RandomCookie: GMT: 1308393557 bytes = { 81, 129, 30, 234, 206, 134, 210,
> 218, 170, 130, 85, 15, 37, 247, 89, 189, 135, 213, 205, 15, 19, 38, 77, 90,
> 224, 246, 175, 61 }
> Session ID: {}
> Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA,
> TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_RC4_128_SHA, TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_RC4_128_SHA,
> TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
> TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA,
> TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
> TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA,
> SSL_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
> TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
> SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, 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, TLS_EMPTY_RENEGOTIATION_INFO_SCSV]
> Compression Methods: { 0 }
> ***
> ActiveMQ Task-2, fatal error: 40: no cipher suites in common
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> ActiveMQ Task-2, SEND TLSv1 ALERT: fatal, description = handshake_failure
> ActiveMQ Task-2, WRITE: TLSv1 Alert, length = 2
> ActiveMQ Task-1, fatal: engine already closed. Rethrowing
> javax.net.ssl.SSLHandshakeException: no cipher suites in common
> ...
> </snip>
>
> Running the *exact same test* changing only the brokers transport scheme
> from "nio+ssl" to "ssl" and the ssl connection is established correctly and
> the test behaves as expected wrt clientAuth, etc.
>
> I was digging around a little, and I'm not really sure if this is
> correct... but it does not look like the nio+ssl transport server is
> getting the ssl serversocketfactory instead which
> NIOSSLTransportFActory.createSocketFactory() should be returning. Actually
> when running the tests above I don't see that method called at all. I also
> dropped a breakpoint at NIOSSLTransportFactory:51
>
>
> (
> https://skitch.com/jasondillon/gw6ft/nio-ssl-w-programatic-key-trust-store-configuration)
>
> And then started to inspect the variables in scope, and it looks like the
> serverSocketFactory instance given is from
> NIOTransportFactory.createServerSocketFactory() return:
>
>
> (
> https://skitch.com/jasondillon/gw6fu/nio-ssl-w-programatic-key-trust-store-configuration)
>
> SSL makes my head want to explode some times. The NIO transport code and
> the SSL version of it is a little more complex to follow how its supposed
> to work vs. the SSL layer on-top of the TCP transport.
>
> Anyways, I'm not sure if the socket factory is an issue here or not, but
> it could be related? I'm also guessing that programatic access using
> nio+ssl hasn't been used that muck since the SslBrokerFactory has not been
> updated to deal with setting the SslContext for nio+ssl scheme (as shown in
> ExtBrokerService above)?
>
> The NIOSSLTransportBrokerTest appears to pass:
>
> <snip>
> -------------------------------------------------------
> T E S T S
> -------------------------------------------------------
>
> Running org.apache.activemq.transport.nio.NIOSSLTransportBrokerTest
> Tests run: 129, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 261.187
> sec
> </snip>
>
> ... so I'm guessing that configuring the trust/keystore bits work okay
> when configuration them globally via javax.net.ssl.* properties?
>
> * * *
>
> Does anyone have any idea what might be going on here which would cause
> "no cipher suites in common" errors when using "nio+ssl" when "ssl" works
> just fine?
>
> Thanks,
>
> --jason
>
>
>