[jboss-jira] [JBoss JIRA] (WFLY-11200) Messaging-activemq integration code alters the JMS client's enabled protocols via TransportConfiguration

[Petr Kremensky (Jira)]

    [ https://issues.jboss.org/browse/WFLY-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13649951#comment-13649951 ] 

Petr Kremensky edited comment on WFLY-11200 at 10/18/18 9:25 AM:
-----------------------------------------------------------------

WFLY-9096 should be reverted as it forces client to use "TLSv1,TLSv1.1,TLSv1.2".
{noformat}
Oracle 1.8.0_181
engine.getEnabledProtocols()
result = {String[4]@5733} 
 0 = "SSLv2Hello"
 1 = "TLSv1"
 2 = "TLSv1.1"
 3 = "TLSv1.2"

IBM 1.8.0_181
engine.getEnabledProtocols()
result = {String[1]@2017} 
 0 = "TLSv1"
{noformat}
client running on IBM has different set of protocols enabled. Test mentioned in WFLY-9096 should be fixed by either enabling TLSv1 on server, or adding -Dcom.ibm.jsse2.overrideDefaultTLS=true property to client (tested the other option now, and work as expected). This should be also documented.


was (Author: pkremens):
WFLY-9096 should be reverted as it forces client to use "TLSv1,TLSv1.1,TLSv1.2".
{noformat}
Oracle 1.8.0_181
engine.getEnabledProtocols()
result = {String[4]@5733} 
 0 = "SSLv2Hello"
 1 = "TLSv1"
 2 = "TLSv1.1"
 3 = "TLSv1.2"

IBM 1.8.0_181
engine.getEnabledProtocols()
result = {String[1]@2017} 
 0 = "TLSv1"
{noformat}
client running on IBM has different set of protocols enabled. Test mentioned in WFLY-9096 should be fixed by either enabling TLSv1 on server, or adding -Dcom.ibm.jsse2.overrideDefaultTLS=true property to client. This should be also documented.

> Messaging-activemq integration code alters the JMS client's enabled protocols via TransportConfiguration
> --------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-11200
>                 URL: https://issues.jboss.org/browse/WFLY-11200
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>            Reporter: Petr Kremensky
>            Assignee: Jeff Mesnil
>            Priority: Major
>
> Integration code of messaging-activemq sets enabledProtocols=\["TLSv1,TLSv1.1,TLSv1.2"\] property to NettyConnector lookedup by the client. This behaviour was introduced by WFLY-9096 (https://github.com/wildfly/wildfly/pull/11673/files).
> https://github.com/wildfly/wildfly/pull/11673/files#diff-64b7f8a3e5eb2234f8bc8cbdebd01799R373
> {code}
> parameters.putIfAbsent(TransportConstants.ENABLED_PROTOCOLS_PROP_NAME, "TLSv1,TLSv1.1,TLSv1.2");
> {code}
> https://github.com/apache/activemq-artemis/blob/2.6.3/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnector.java#L355
> {code}
> enabledProtocols = ConfigurationHelper.getStringProperty(TransportConstants.ENABLED_PROTOCOLS_PROP_NAME, TransportConstants.DEFAULT_ENABLED_PROTOCOLS, configuration);
> {code}
> NettyConnector prefers the enabled protocols obtained from integration code to ones defined on client side - possibly forces client to use less secured protocol than client wants.
> https://github.com/apache/activemq-artemis/blob/2.6.3/artemis-core-client/src/main/java/org/apache/activemq/artemis/core/remoting/impl/netty/NettyConnector.java#L550
> {code}
> ...
> String[] originalProtocols = engine.getEnabledProtocols();
> ...
> if (enabledProtocols != null) { // true with WFLY-9096
>    try {
>       engine.setEnabledProtocols(SSLSupport.parseCommaSeparatedListIntoArray(enabledProtocols));
>    } catch (IllegalArgumentException e) {
>       ActiveMQClientLogger.LOGGER.invalidProtocol(SSLSupport.parseArrayIntoCommandSeparatedList(engine.getSupportedProtocols()));
>       throw e;
>    }
> } else {
>    engine.setEnabledProtocols(originalProtocols);
> }
> ...
> {code}
> *Reproduce*
> {code:bash}
> WORKSPACE=`pwd`
> WILDFLY=${WORKSPACE}/wildfly
> TESTSUITE=${WORKSPACE}/eap-tests-hornetq
> SERVERS=${WORKSPACE}/servers
> export JBOSS_HOME_1=${SERVERS}/server1/jboss-eap
> export JBOSS_HOME_2=${SERVERS}/server2/jboss-eap
> export JBOSS_HOME_3=${SERVERS}/server3/jboss-eap
> export JBOSS_HOME_4=${SERVERS}/server4/jboss-eap
> # setup testing server
> cd $WORKSPACE
> git clone git at github.com:wildfly/wildfly.git
> cd $WILDFLY
> mvn clean install -DskipTests -pl dist -am
> cd dist/target
> zip -r /tmp/wildfly.zip wildfly-*-SNAPSHOT
> # setup testsuite
> cd $WORKSPACE
> git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git 
> mkdir $SERVERS
> cd $SERVERS
> groovy -DEAP_ZIP_URL=file:///tmp/wildfly.zip ${TESTSUITE}/scripts/PrepareServers7.groovy 
> # run the reproducer
> cd $TESTSUITE/jboss-hornetq-testsuite
> mvn clean test -Dtest=ElytronSslAuthenticationTestCase#testOneWaySslOverSSLv3Jms -pl tests-eap7 -am
> {code}
> *Test details:*
> *server* supports TLSv1.1
> {code:xml}
> <server-ssl-contexts>
>     <server-ssl-context name="server-ssl-context" protocols="TLSv1.1" need-client-auth="false" key-manager="key-manager-name_server-ssl-context"/>
> </server-ssl-contexts>
> {code}
> *client* is forced (byteman rule) to use the SSLv3
> *Actual:*
> Connection is made.
> *Expected:*
> javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)



--
This message was sent by Atlassian Jira
(v7.12.1#712002)