[jira] [Commented] (AMQNET-572) Failover crashes when AMQ Server enforces TLS 1.2

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/AMQNET-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16208158#comment-16208158 ] 

ASF GitHub Bot commented on AMQNET-572:
---------------------------------------

GitHub user dtaflin opened a pull request:

    https://github.com/apache/activemq-nms-openwire/pull/3

    Fix for NMS failover/TLS bug, AMQNET-572, by saving an Ssl context

    Proposed fix for https://issues.apache.org/jira/browse/AMQNET-572

You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/dtaflin/activemq-nms-openwire fix-failover

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/activemq-nms-openwire/pull/3.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #3
    
----
commit d04851c2d6b5ad30dc01b3829d495d46c5800b0f
Author: dtaflin <dt...@taser.com>
Date:   2017-10-17T18:48:42Z

    Fix for NMS failover/TLS bug, AMQNET-572, by saving an Ssl context

----


> Failover crashes when AMQ Server enforces TLS 1.2
> -------------------------------------------------
>
>                 Key: AMQNET-572
>                 URL: https://issues.apache.org/jira/browse/AMQNET-572
>             Project: ActiveMQ .Net
>          Issue Type: Bug
>            Reporter: Dan Taflin
>            Priority: Critical
>
> When using the FailoverTransport with underlying SslTransports, and specifying Tls12 as the SslProtocol, the initial connection to the ActiveMQ server succeeds in establishing a TLS v1.2 session. But upon failover, when it tries to reconnect, the Tls12 specification is lost and the NMS client reverts to the default, which appears to be TLS 1.0.
> The consequence is that it is impossible to enforce TLS 1.2 on the server, because although the initial connection would succeed, subsequent ones crash the client.
> Here's a sample failover transport URL:
> {{failover:(ssl://server1.example.com:61616?transport.sslProtocol=Tls12,ssl://server2.example.com:61616?transport.sslProtocol=Tls12)}}
> I've traced the issue to the FailoverTransport.DoConnect() method, which, when obtaining the ConnectList in order to obtain a url to connect to, obtains a url without a querystring. So in the above example, transport.sslProtocol=Tls12 is gone. The source of this truncated url is the ConnectionControl command marshalled from the server.
> The solution would seem to be to create an SslContext class to keep track of the sslProtocol, similar to how the java version works. I have built a working prototype for us to use locally and would be willing to make it available.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)