activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Dillon <ja...@planet57.com>
Subject Re: nio+ssl w/programatic {key|trust}store configuration
Date Tue, 03 Jan 2012 23:41:49 GMT
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 <jason@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
> 
> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message