Disabling SSLv3 in JBoss Fuse 6.x and JBoss A-MQ 6.x

Solution Verified - Updated -

Environment

  • Red Hat JBoss Fuse

    • 6.2.1
    • 6.2
    • 6.1.1
    • 6.1
    • 6.0
  • Red Hat JBoss A-MQ

    • 6.2.1
    • 6.2
    • 6.1.1
    • 6.1
    • 6.0

Issue

Resolution

JBoss Fuse and JBoss A-MQ come with multiple components that support SSL.
So disabling SSLv3 to guard against the Poodle vulnerability (CVE-2014-3566) may require changing the SSL configuration in more than just one place, depending on the components that use SSL.

Embedded Pax-Web Jetty server

A Pax Web Jetty based HTTP server is deployed out of the box in JBoss Fuse and JBoss A-MQ, however it is not SSL enabled.
If you re-configured the Pax Web server to be SSL enabled, then you can disable SSLv3 support in Pax Web by adding the following Jetty configuration in $JBOSS_FUSE/etc/jetty.xml. This will only affect the Jetty server used by Pax Web. All of the OSGi HTTP services from Pax Web use Jetty and this configuration. As well as that, both CXF and camel-jetty use this configuration by default.

<Call name="addConnector">
    <Arg>
        <New class="org.eclipse.jetty.server.ssl.SslSocketConnector">
           <Arg>
              <New class="org.eclipse.jetty.http.ssl.SslContextFactory">
                  <!-- in Fuse 6.0, please replace above FQN with "org.eclipse.jetty.util.ssl.SslContextFactory" -->
                  <Set name="ExcludeProtocols">
                      <Array type="java.lang.String">
                          <Item>SSLv3</Item>
                      </Array>
                  </Set>
              </New>
           </Arg>
           <Set name="Port">8183</Set>
           <Set name="keystore">/home/jshepher/Documents/cases/01264474/server.keystore</Set>
           <Set name="password">mykeystorepass</Set>
           <Set name="keyPassword">mykeystorepass</Set>
           <Set name="certAlias">jboss</Set>
       </New>
    </Arg>
</Call>

You'll still need to have org.osgi.service.http.secure.enabled=true set in etc/org.ops4j.pax.web.cfg.

If you want to obfuscate the passwords set in the above configuration, please visit KCS 1240933 for instructions.

Note: If you configure SSL using the configuration above, it will override the configuration in etc/org.ops4j.pax.web.cfg. That means that you have to move your existing keystore file reference, and password from etc/org.ops4j.pax.web.cfg to $JBOSS_FUSE/etc/jetty.xml if you used the information from the documentation here:

https://access.redhat.com/documentation/en-US/Red_Hat_JBoss_Fuse/6.1/html/Security_Guide/WebConsole.html

Note that SSLv2 is not available with the Jetty SSL Connector.


Embedded ActiveMQ broker

The default embedded ActiveMQ broker configuration does not create an SSL transport connector. If you manually added an SSL transport connector, then you restrict the SSL protocols supported by the broker using the option transport.enabledProtocols:

<transportConnector name="ssl" uri="ssl://localhost:61617?transport.enabledProtocols=TLSv1,TLSv1.1,TLSv1.2></transportConnector>

This configuration restricts the SSL connector of ActiveMQ to only support TLSv1, TLSv1.1, TLSv1.2. SSLv3 will not be supported.

The Poodle vulnerability has 2 parts. The first part being the ability for a 'man in the middle' to cause an error during protocol negotiation, which then results in the client requesting a less secure protocol. However this is only relevant for HTTPS, and web browsers. Therefore ActiveMQ SSL clients are not going to able to be exploited by this type of attack, as they won't renegotiate the protocol in the same way.

"Any website that supports SSLv3 is vulnerable to POODLE, even if it also supports more recent versions of TLS. In particular, these servers are subject to a downgrade attack, in which the attacker tricks the browser into connecting with SSLv3. This relies on a behavior of browsers called insecure fallback, where browsers attempt to negotiate lower versions of TLS or SSL when connections fail."

Reference, https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0/


Camel components using SSLContextParameters

Customer applications using HTTPS that create connections using SSLContextParameters with a default protocol of "TLS" are vulnerable. To mitigate this vector, customers need to explicitly set the list of protocols permitted for use in their application. This could be done as shown below.

    SSLContextParameters sslContextParameters = new SSLContextParameters();
    sslContextParameters.setSecureSocketProtocols(new SecureSocketProtocolsParameters());
    sslContextParameters.getSecureSocketProtocols().getSecureSocketProtocol().add("TLSv1.2");
    sslContextParameters.getSecureSocketProtocols().getSecureSocketProtocol().add("TLSv1.1");
    sslContextParameters.getSecureSocketProtocols().getSecureSocketProtocol().add("TLSv1");

or in Spring / Blueprint

 <camel:sslContextParameters id="sslContextParameters">
    <camel:secureSocketProtocols>
      <camel:secureSocketProtocol>TLSv1</camel:secureSocketProtocol>
      <camel:secureSocketProtocol>TLSv1.1</camel:secureSocketProtocol>
      <camel:secureSocketProtocol>TLSv1.2</camel:secureSocketProtocol>
    </camel:secureSocketProtocols>
  </camel:sslContextParameters>

using either namespace xmlns:camel="http://camel.apache.org/schema/spring" or xmlns:camel="http://camel.apache.org/schema/blueprint".
Not all SSL enabled Camel components support the SSLContextParamater. For a list of supported components, consult this Camel documentation.


CXF Endpoints

SSL enabled CXF endpoints can either use the Pax-Web HTTP stack (if they run inside a Karaf OSGi container) or create their own HTTP stack.
In case of using Pax-Web's HTTP stack, the notes from section 'Embedded Pax-Web Jetty server' apply for disabling support for SSLv3.
If the CXF endpoint uses its own HTTP stack (by specifying its own hostname and port number) then an update to one of the following patches is needed in order to disable SSLv3.
JBoss Fuse 6.1 Rollup 1 Patch 2
JBoss Fuse 6.0 Rollup 2 Patch 4

JBoss Fuse 6.2 and higher already has SSLv2 and SSLv3 disabled by default.


LDAP SSL

For customers connecting to an Apache Directory Server configured with an SSL endpoint, you can configure the connection to use TLSv1 instead of the default SSL by setting the ssl.protocol attribute in the configuration as shown below. This is configured in the ldap-module.xml file you created when enabling LDAP as per Enable LDAP Authentication in the OSGi Container.

<jaas:config name="karaf" rank="1">
    <jaas:module className="org.apache.karaf.jaas.modules.ldap.LDAPLoginModule" flags="required">
      initialContextFactory=com.sun.jndi.ldap.LdapCtxFactory
      connection.username=uid=admin,ou=system
      connection.password=secret
      connection.protocol=
      connection.url = ldaps://localhost:10636
      user.base.dn = ou=users,ou=system
      user.filter = (uid=%u)
      user.search.subtree = true
      role.base.dn = ou=users,ou=system
      role.filter = (uid=%u)
      role.name.attribute = ou
      role.search.subtree = true
      authentication = simple     
      ssl.protocol=TLSv1
      ssl.truststore=truststore
      ssl.algorithm=PKIX
    </jaas:module>
  </jaas:config>

For more information with regards to enabling SSL for LDAP, refer to Enable SSL/TLS on the LDAP Connection.


Management Console JMX

Edit the $FUSE_HOME/etc/org.apache.karaf.management.cfg file to specify the secureProtocol property. For example,

secured = true
secureProtocol = TLSv1
keyAlias = jbossalias
keyStore = sample_keystore
trustStore = sample_keystore

For more information regarding SSL configuration for JMX, refer to Enabling Remote JMX SSL

Diagnostic Steps

  • Run the SSLv3 checker against your application using the configued SSL port

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.