Ulf Lilleengen created PROTON-1355: -------------------------------------- Summary: 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