Willy, Am 25.04.2018 um 12:16 schrieb Willy Tarreau: > 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. *snip* > >> 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. >
Unfortunately it’s not exactly easy to detect this condition using haproxy. I asked on May 7th, 2017 on the list (thread: Compare against variable string in ACL, Message-ID: <[email protected]>, https://www.mail-archive.com/[email protected]/msg26014.html). The solution I got from "Holger Just" was: > http-request set-header X-CHECKSNI %[req.hdr(host)]==%[ssl_fc_sni] if > { ssl_fc_has_sni } > http-request deny if { ssl_fc_has_sni } ! { > hdr(X-CHECKSNI) -m reg -i ^(?<host>.+)==\1$ } > http-request del-header X-CHECKSNI which works well, but is not intuitive and requires PCRE. I have contemplated to add a patch with a `ssl_sni_http_host_mismatch` fetch, but I wasn't quite sure where to place it (it requires both http and ssl and thus is misplaced in both) and what parameters to pass (meaning SMP_USE_HRQHV et al). And thus I gave up. Not having this validation opens up possible security issues (validation of client certificates is based on SNI, routing is possibly based on the Host header). Personally I require SNI for everything and select the backends based on SNI and not the Host header. If you could give me some pointers on where to put such a fetch and what parameters to set I'd appreciate it. Or tell me that such a fetch is stupid, because it mixes information from different layers. Best regards Tim Düsterhus
