Add the .authority field to backend definitions.
If the .via field is also set, then the value of .authority is set as the authority TLV in the PROXY header. This gives the "true" backend (usually the ssl-onloader) the opportunity to set the SNI (HostName field) from the TLV value, for the TLS handshake with the remote backend. This mandates that PROXYv2 is always used with a via backend (since only version 2 supports TLVs). If the value of .authority is the empty string, then the TLV is not sent. If .authority is not set for the backend, then fall back to .host_header, which itself may have been a fallback to .host. Note that if neither .authority nor .host_header is set, and .host is set to an IP address, then the IP address is forwarded as the SNI value, which is not permitted for HostName (RFC4366 ch 3.1). So users are advised to set either .authority or .host_header, or set .authority="", when .via is set. Usage note with haproxy: To enable sending SNI when haproxy is used as a TLS onloader, ``sni fc_pp_authority`` needs to be used with the backend configuration. Full usage example with haproxy 2.2: listen sslon mode tcp maxconn 1000 bind /shared/varnish_haproxy/haproxy_sslon accept-proxy mode 777 stick-table type ip size 100 stick on dst server s00 0.0.0.0:443 ssl ca-file /etc/ssl/certs/ca-bundle.crt alpn http/1.1 sni fc_pp_authority server s01 0.0.0.0:443 ssl ca-file /etc/ssl/certs/ca-bundle.crt alpn http/1.1 sni fc_pp_authority # ... A higher number of servers improves TLS session caching.
Showing
Please register or sign in to comment