On Wed, Apr 25, 2018 at 09:48:13AM +0000, GALLISSOT VINCENT wrote: > I don't see a case were one would define a different check-sni or sni values > from the "Host" header.
It definitely must match in HTTP. However there's nothing making it mandatory to send HTTP checks, let alone a Host header field (eg: if sending a simple HTTP/1.0 request). However I'm noting the comment, because once we're able to more easily configure the HTTP checks, we could imagine that we'd always use SNI when "sni" is configured on the server line and an http check is in use. > I'm not even sure that differentiate "Host" header from SNI values is > possible on softwares like Nginx or Apache. It should not, that would be a violation of HTTP over TLS. > We should always use SNI & check-sni as the same value as the "Host" header > value, Yes, when we have one :-) > which in many cases should be the same value as the FQDN from the server line. This is where it's not always the case. Very commonly you'll have the individual server name (server1, server2, etc) and you need the application Host header. > I also think SNI should be defaulted when using ssl over server backend. We could possibly consider making it a default in a future version, indeed, but only once we have the ability to automatically retrieve correct values. > Check-sni should default to the same value as sni but re-writable. Except that SNI comes from forwarded traffic and there's no forwarded traffic with the checks to extract the information from. > CDN providers like CloudFront or Akamai are using more and more SNI > by blowing up prices on non-sni configurations (CloudFront bills > 600$/month/vhost to avoid SNI) I can easily understand why they're doing this. IP addresses are becoming rare and it's a shame that some sites continue to waste them. With the rapid growth of SSL over the last few years, I can easily imagine that many sites have started to request their own IP addresses for no really valid reason (I believe that MSIE6 was the last browser not to support SNI but I could be wrong). Willy
