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