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 > > > > > > > >
