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:
<dd3213f8-3c67-29d2-d438-5c1994dcf...@bastelstu.be>,
https://www.mail-archive.com/haproxy@formilux.org/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

Reply via email to