Evgeni Golov created PROTON-2434:
------------------------------------
Summary: Container.connect doesn't set virtual_host by default,
making peer verification harder than it should be
Key: PROTON-2434
URL: https://issues.apache.org/jira/browse/PROTON-2434
Project: Qpid Proton
Issue Type: Bug
Affects Versions: proton-c-0.35.0
Reporter: Evgeni Golov
In 0.35 proton-c started to default to PN_SSL_VERIFY_PEER_NAME in client mode,
which is good. However, it seems that it does not (by default) extract the peer
name from the URL, so a connection can not be established, even if the certs
and everything matches, as there is no name to verify against.
Looking at the Ruby examples
([https://qpid.apache.org/releases/qpid-proton-0.35.0/proton/ruby/examples/ssl_send.rb.html),]
you suggest to roll back the default VERIFY_PEER_NAME to ANONYMOUS_PEER:
{code:ruby}
ssl_domain =
Qpid::Proton::SSLDomain.new(Qpid::Proton::SSLDomain::MODE_CLIENT)
ssl_domain.peer_authentication(Qpid::Proton::SSLDomain::ANONYMOUS_PEER)
c = container.connect(@url, { :ssl_domain => ssl_domain })
{code}
And indeed, dropping the ANONYMOUS_PEER fails the connection attempt.
Instead, we can explicitly set the virtual_host of the connection, thus
allowing the PEER_NAME verification to succeed:
{code:ruby}
ssl_domain =
Qpid::Proton::SSLDomain.new(Qpid::Proton::SSLDomain::MODE_CLIENT)
c = container.connect(@url, { :ssl_domain => ssl_domain, :virtual_host =>
URI.parse(@url).host })
{code}
However, I think this is cumbersome and makes users lifes harder than they
should be.
If container.connect would automatically set the virtual_host to the host part
of the URL (unless it was defined by the user), SSL verification would just
work.
FWIW, I only tested this all with the Ruby bindings on Ruby 2.7, OpenSSL
1.0.2k-21.el7_9.x86_64 (CentOS 7), so this might behave differently on other
environments.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
