qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gordon Sim <g...@redhat.com>
Subject Re: Qpid Proton SSL and SNI
Date Mon, 14 Nov 2016 23:51:08 GMT
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).

> 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


Mime
View raw message