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: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
