Details
-
Improvement
-
Status: Closed
-
Minor
-
Resolution: Fixed
-
None
-
None
-
Patch
Description
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
Attachments
Issue Links
- links to
