qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Qpid Proton SSL and SNI
Date Tue, 15 Nov 2016 16:38:11 GMT
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 place.

> 
> > 
> > Would it make sense to add the peer_hostname attribute to the
> > pn_ssl_domain_t instance, and use that when configuring the
> > pn_ssl_t
> > internally (in addition to keeping todays API)?
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org


Mime
View raw message