> On Nov. 18, 2016, 2:48 p.m., Alan Conway wrote:
> > Do we need the explicit sni setting? i.e. are there use cases where you 
> > really need to set SSL SNI = X and AMQP/SASL host = Y where X != Y? If 
> > there are then ship it. If not then I'd prefer to drop the ssl_sni option 
> > and make virtual_host the One True Fake Hostname for all security purposes. 
> > This story is confusing enough already.
> 
> Alan Conway wrote:
>     To justify: I think embedding SSL in proton was a mistake from the get 
> go, in future it should be handled externally, using the user's choice of 
> tools, configured as normal for those tools. Proton should make it easy to 
> integrate by providing access to relevant *AMQP* settings (virtual_host, SASL 
> user/pass etc.) but *not* by exporting random config settings from a 
> randomly-chosen SSL tool (openssl) as part of proton's top-level API. Openssl 
> config is not suitable for windows SSL, the Go TLS stack, native python/ruby 
> SSL etc. I know SNI is common to all SSL stacks, but SSL is not the only 
> encryption layer in the world. I want to get proton back to doing just AMQP 
> and provide extension points to integrate whatever protocol layers the user 
> wants. It's not realistic now so if we need this feature short term go ahead. 
> However someday I will cut the Gordian Knot so I'd like to avoid expanding 
> the amount of pesky non-AMQP config I will have to untangle from the 
> top-level API.

I think Gordon was trying to account for my mentioning the previous change was 
altering the existing behaviour in a way that it would no longer be possible to 
have the connection hostname and SNI hostname details match while changing the 
AMQP sasl/open host, quite possibly making the python bits act differently from 
everything else (including the .net client Ken referenced). I agree it would 
often make sense for them all to be the same, though at that point I'd also 
tend toward having the connection host match so that you didnt need to set 
anything else at all.


- Robbie


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/53876/#review156298
-----------------------------------------------------------


On Nov. 18, 2016, 3:26 p.m., Gordon Sim wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53876/
> -----------------------------------------------------------
> 
> (Updated Nov. 18, 2016, 3:26 p.m.)
> 
> 
> Review request for qpid, Alan Conway, Chug Rolke, Justin Ross, Kenneth 
> Giusti, and Robbie Gemmell.
> 
> 
> Repository: qpid-proton-git
> 
> 
> Description
> -------
> 
> Ulf's fix for https://issues.apache.org/jira/browse/PROTON-1355 allows you to 
> control the sni via the existing virtual host option. For cases where you 
> want the sni to be different from the hostname in the open frame, this patch 
> adds an explicit option.
> 
> 
> Diffs
> -----
> 
>   proton-c/bindings/python/proton/reactor.py 3562aa9 
> 
> Diff: https://reviews.apache.org/r/53876/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Gordon Sim
> 
>

Reply via email to