This issue was observed by Vinith. He had a sni entry for one domain that had client ip address restrictions specified in sni.yaml via the ip_allow action. He also had the proxy.config.http.host_sni_policy set to the default value of 2 which should be cross checking host header for security specific sni policies if the sni and the host header value do not match. However, he was able to evade the ip_allow policy by using a different SNI value but using the host header for the sensitive domain.
I was able to reproduce this with the following sni.yaml file.
sni:
- fqdn: bar
ip_allow: '127.0.0.1'
When run from an adjacent machine, the this failed as expected.
curl -k --resolve 'bar:4443:192.168.1.12' -d stuff https://bar:4443/port
And this succeeded as expected.
curl -k --resolve 'bar:4443:192.168.1.12' -d stuff https://bar:4443/port
But this also succeeded which means the host_sni_policy setting was not working for the ip_allow action
curl -k --resolve 'foo:4443:192.168.1.12' -d stuff https://foo:4443/post -H 'Host: bar'
This issue was observed by Vinith. He had a sni entry for one domain that had client ip address restrictions specified in sni.yaml via the ip_allow action. He also had the proxy.config.http.host_sni_policy set to the default value of 2 which should be cross checking host header for security specific sni policies if the sni and the host header value do not match. However, he was able to evade the ip_allow policy by using a different SNI value but using the host header for the sensitive domain.
I was able to reproduce this with the following sni.yaml file.
When run from an adjacent machine, the this failed as expected.
And this succeeded as expected.
But this also succeeded which means the host_sni_policy setting was not working for the ip_allow action