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 <al-hapr...@none.at> 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) <address> (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
> >
> >
>
>

Reply via email to