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

["ASF subversion and git services (Jira)" <ji...@apache.org>]

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

ASF subversion and git services commented on AMQNET-572:
--------------------------------------------------------

Commit ed08387908aafa920f5435c3aaa9b6fc79c5fb91 in activemq-nms-openwire's branch refs/heads/main 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: 7h 10m
>  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)