[
https://issues.apache.org/jira/browse/AMQNET-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310927#comment-17310927
]
ASF subversion and git services commented on AMQNET-572:
--------------------------------------------------------
Commit ed08387908aafa920f5435c3aaa9b6fc79c5fb91 in activemq-nms-openwire's
branch refs/heads/master from Michael André Pearce
[ https://gitbox.apache.org/repos/asf?p=activemq-nms-openwire.git;h=ed08387 ]
Merge pull request #16 from brudo/fix-failover-dtaflin-reloc
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
> Attachments: Archivos-1.zip, failoverSslContext.patch
>
> Time Spent: 6h 40m
> Remaining Estimate: 0h
>
> 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
(v8.3.4#803005)
