[
https://issues.apache.org/jira/browse/PROTON-1355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15676197#comment-15676197
]
ASF GitHub Bot commented on PROTON-1355:
----------------------------------------
GitHub user lulf opened a pull request:
https://github.com/apache/qpid-proton/pull/90
PROTON-1355: Set ssl.peer_hostname to virtual_host if specified
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/lulf/qpid-proton PROTON-1355
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/qpid-proton/pull/90.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 #90
----
commit d49ab3f96082a29489d2f1fc8880590d74338f68
Author: Ulf Lilleengen <l...@redhat.com>
Date: 2016-11-18T08:52:02Z
PROTON-1355: Set ssl.peer_hostname to virtual_host if specified
----
> Allow controlling peer_hostname independently of connection url
> ---------------------------------------------------------------
>
> Key: PROTON-1355
> URL: https://issues.apache.org/jira/browse/PROTON-1355
> Project: Qpid Proton
> Issue Type: Improvement
> Components: python-binding
> Reporter: Ulf Lilleengen
> Priority: Minor
>
> I've made a patch that sets SSL peer_hostname to virtual_host if set, and
> falls back to the url hostname if not.
> On 15. nov. 2016 17:38, Alan Conway wrote:
> > On Mon, 2016-11-14 at 23:51 +0000, Gordon Sim wrote:
> >> > On 14/11/16 14:18, Ulf Lilleengen wrote:
> >>> > >
> >>> > > I've been playing around with setting Server Name Indication (SNI)
> >>> > > when using the qpid proton python bindings.
> >>> > >
> >>> > > For configuring SSL, it seems to be expected that configuration
> >>> > > parameters come from a SSLDomain python object, which maps to the
> >>> > > underlying pn_ssl_domain_t in proton-c.
> >>> > >
> >>> > > Today, setting SNI is done through the pn_ssl_t instance using
> >>> > > 'pn_ssl_set_peer_hostname'. The pn_ssl_t instance does not seem to
> >>> > > be
> >>> > > exposed in the end APIs in the same way as pn_ssl_domain_t, at
> >>> > > least
> >>> > > not in the python bindings. I tried to work around this in the
> >>> > > python
> >>> > > bindings by passing an extra parameter in addition to the
> >>> > > ssl_domain
> >>> > > instance on connect(), but it didn't seem like a good approach.
> >> >
> >> > There is already a virtual_host keyword argument for connect(). This
> >> > is
> >> > used to control the hostname field in the AMQP open frame. That is
> >> > similar to SNI in TLS. The AMQP spec says:
> >> >
> >> > The TLS client peer SHOULD use the server name indication
> >> > extension as described in RFC-4366 [RFC4366].
> >> >
> >> > If it does so, then it is undefined what happens if this
> >> > differs from hostname in the sasl-init and open frame
> >> > frames.
> >> >
> >> > So perhaps using the virtual_host, if specified, for the
> >> > peer_hostname
> >> > would make sense. (If not specified it could fallback to the hostname
> >> > in
> >> > the url).
> > I think that is what we did with virtual_host a while back, but I am
> > not sure exactly what was completed and what was discussed. IIRC the
> > discussion was that AMQP hostname/peer_host should be set to
> > virtual_host if that is set, or fall-back to the URL hostname if not.
> > The idea was exactly to avoid the need to muck about with ssl_domains
> > and whatnot, and set the "virtual" hostname in just one
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org
For additional commands, e-mail: dev-h...@qpid.apache.org
