Re: 'sni' parameter - reasonable default/implicit setting ?
That looks right on - thanks for the pointer ! I couldn't tell from the brief gander I took - works the same for 'server-template' as for 'server' ? On Sat, Jul 27, 2019 at 2:53 AM Aleksandar Lazic wrote: > Hi. > > Am 27.07.2019 um 00:24 schrieb Jim Freeman: > > For outgoing TLS connections, might haproxy be taught to use a reasonable > > default/implicit value 'sni' [1] expression/behavior that would 'first > do no > > harm'[2], and usually be correct, in the absence of an explicit > expression ? > > (Understood that haproxy depends on an SSL lib) > > > > E.g.; req.hdr(host) if it is set, else server(-template) (if > it is > > cfg'd as name, not IP), else ssl_fc_sni for bridged HTTPS, else ... ? > > > > If SNI [3] is used vs. an endpoint that doesn't require/utilize it, is > it always > > innocuous ? > > > > Are increasing demands by service providers that clients (e.g.; haproxy > vs. an > > SSL endoint) send SNI inevitable? Or is some alternative pending? > > I think this is similar Ideas as the vhost patch intend to solve. > > https://www.mail-archive.com/haproxy@formilux.org/msg34532.html > > I think the patch should be adopted for `mode tcp` also, jm2c. > > > Just wondering, > > ...jfree > > Best Regards > Aleks > > > [1] http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#sni > > [2] https://en.wikipedia.org/wiki/Primum_non_nocere > > https://en.wikipedia.org/wiki/Robustness_principle > > [3] https://en.wikipedia.org/wiki/Server_Name_Indication > > > > > >
Re: 'sni' parameter - reasonable default/implicit setting ?
Hi. Am 27.07.2019 um 00:24 schrieb Jim Freeman: > For outgoing TLS connections, might haproxy be taught to use a reasonable > default/implicit value 'sni' [1] expression/behavior that would 'first do no > harm'[2], and usually be correct, in the absence of an explicit expression ? > (Understood that haproxy depends on an SSL lib) > > E.g.; req.hdr(host) if it is set, else server(-template) (if it is > cfg'd as name, not IP), else ssl_fc_sni for bridged HTTPS, else ... ? > > If SNI [3] is used vs. an endpoint that doesn't require/utilize it, is it > always > innocuous ? > > Are increasing demands by service providers that clients (e.g.; haproxy vs. an > SSL endoint) send SNI inevitable? Or is some alternative pending? I think this is similar Ideas as the vhost patch intend to solve. https://www.mail-archive.com/haproxy@formilux.org/msg34532.html I think the patch should be adopted for `mode tcp` also, jm2c. > Just wondering, > ...jfree Best Regards Aleks > [1] http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#sni > [2] https://en.wikipedia.org/wiki/Primum_non_nocere > https://en.wikipedia.org/wiki/Robustness_principle > [3] https://en.wikipedia.org/wiki/Server_Name_Indication > >
'sni' parameter - reasonable default/implicit setting ?
For outgoing TLS connections, might haproxy be taught to use a reasonable default/implicit value 'sni' [1] expression/behavior that would 'first do no harm'[2], and usually be correct, in the absence of an explicit expression ? (Understood that haproxy depends on an SSL lib) E.g.; req.hdr(host) if it is set, else server(-template) (if it is cfg'd as name, not IP), else ssl_fc_sni for bridged HTTPS, else ... ? If SNI [3] is used vs. an endpoint that doesn't require/utilize it, is it always innocuous ? Are increasing demands by service providers that clients (e.g.; haproxy vs. an SSL endoint) send SNI inevitable? Or is some alternative pending? Just wondering, ...jfree [1] http://cbonte.github.io/haproxy-dconv/1.9/configuration.html#sni [2] https://en.wikipedia.org/wiki/Primum_non_nocere https://en.wikipedia.org/wiki/Robustness_principle [3] https://en.wikipedia.org/wiki/Server_Name_Indication
