In light of POODLE, it is recommended that the use of SSLv3 be disabled as a hardening measure. This has been already done upstream via jira HORNETQ-1444. The relevant upstream commit is at [1]. We also recommend SSL support be dropped in favor of TLS protocols if feasible. [1] https://github.com/hornetq/hornetq/commit/e9825f22568eacfb40058ce5177497cbaf2af1a0
My understanding is that Jimmy was checking with security if we should back port this one or not based on the security team directives. Justin posted changes for this already on our upstream.. we just need to verify if we should back port this or not. Jimmy?
PR sent: https://github.com/hornetq/hornetq/pull/1957
This is part of 2.3.24.Final, setting to MODIFIED for DR12 (although it probably came in earlier)
Hi Justin, I've tried to connect by standalone JMS client with SSLv3 and client could create connection and send messages to queue. Server just logged warning: 16:03:57,088 WARN [org.hornetq.core.server] (Old I/O server boss ([id: 0x04d786c5, /127.0.0.1:5445])) HQ222190: Disallowing use of vulnerable protocol: SSLv2Hello. See http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html for more details. 16:03:57,088 WARN [org.hornetq.core.server] (Old I/O server boss ([id: 0x04d786c5, /127.0.0.1:5445])) HQ222190: Disallowing use of vulnerable protocol: SSLv3. See http://www.oracle.com/technetwork/topics/security/poodlecve-2014-3566-2339408.html for more details. Correct behaviour should be that client will not able to create connection. We checked SSLHandler class in netty 3.6.10 and it does not check enabled protocols. In Netty 4+ which is in HornetQ 2.5 there is check for enabled protocols. There is also missing possibility to set "enabled-protocols" parameter for connector. User does not have a way to specify set of protocols to use. Thanks, Mirek
> I've tried to connect by standalone JMS client with SSLv3 and client could create connection and send messages to queue. How did you verify that the client was indeed using SSLv3 and not TLSv1? > We checked SSLHandler class in netty 3.6.10 and it does not check enabled protocols. Netty's behavior here shouldn't be an issue. The enabled protocols are changed on the javax.net.ssl.SSLEngine instance that is passed to the org.jboss.netty.handler.ssl.SslHandler constructor. Netty should be using the engine as is and not modifying it (no matter what version of Netty is used). > There is also missing possibility to set "enabled-protocols" parameter for connector. User does not have a way to specify set of protocols to use. That's correct. This feature was added to later versions but not back-ported to 2.3.x because there's been no customer requests for it.
I've created byteman rule which set only "SSLv3" to enabled protocols in JMS client: RULE "rule to force sslv3" CLASS org.hornetq.core.remoting.impl.netty.NettyConnector METHOD start() AT LINE 473 IF true DO "engine.setEnabledProtocols(new String[] {\"SSLv3\"});" ENDRULE Based on description in this bugzilla, I'd expect that client using SSLv3 protocol won't be able to create connection.
What branch/tag are you working from? I'm trying to verify you're using the right line number in your Byteman rule.
I think your Byteman rule just isn't right. If I manually insert: engine.setEnabledProtocols(new String[] {"SSLv3"}); at the proper point and run a test then the client is unable to connect. The same basic test exists on the HornetQ master branch in org.hornetq.tests.integration.ssl.CoreClientOverOneWaySSLTest.testPOODLE, but that test uses the client's ability to set the enabled protocols on the transport.
I just sent https://github.com/hornetq/hornetq/pull/1973 with a Byteman test that does the job.
You're right, byteman rule was not right. When I tried to add: engine.setEnabledProtocols(new String[] {"SSLv3"}); to NettyConnector.java then I can see that client cannot connect. I'm setting bz as verified.