Squid SNI Inspection results in errors in log

[aneillans]

When you enable SNI inspection only on Squid, you encounter a large number of errors in the log such as:

SECURITY ALERT: Host header forgery detected on local=[blah-ip]:443 remote=[my-ip]:52382 FD 12 flags=33 (local IP does not match any domain IP)

This is identifiable as something other vendors of Squid have encountered and had to disable, such as: https://github.com/NethServer/squid/blob/c7/SOURCES/squid-3.5.20-ssl-forgery.patch

Forum Thread: https://forum.opnsense.org/index.php?topic=10013.new;topicseen#new

[fichtner]

Work still needs to be done for squid 4 migration, but I'd like to use this opportunity to look closer into the code as the current solution only skips the check unconditionally, but limitations should apply:

http://www.squid-cache.org/Doc/config/host_verify_strict/

    Regardless of this option setting, when dealing with intercepted
    traffic, Squid always verifies that the destination IP address matches
    the Host header domain or IP (called 'authority form URL').

[aneillans]

Happy to help with understanding it's behaviour if required. The issues around this check stems from sites that use multiple IPs bound to a name so get different ips back when client requests Vs squid doing its check. On 13 Feb 2019 07:21, Franco Fichtner notifications@github.com wrote:Work still needs to be done for squid 4 migration, but I'd like to use this opportunity to look closer into the code as the current solution only skips the check unconditionally, but limitations should apply: http://www.squid-cache.org/Doc/config/host_verify_strict/ Regardless of this option setting, when dealing with intercepted traffic, Squid always verifies that the destination IP address matches the Host header domain or IP (called 'authority form URL').

—You are receiving this because you authored the thread.Reply to this email directly, view it on GitHub, or mute the thread.

[fichtner]

@aneillans thanks, ideally we should see if we can inject the expected IP addresses into the verification check... Maybe we could build a subnet check in this case?!

[aneillans]

Subnets probably wouldn't work as no guarantee that a site has IPs on the name within same subnet. We would need to request all IPs for a given name to match against a bit like nslookup does. Make sense?  I'll see if I can find some examples. On 13 Feb 2019 10:01, Franco Fichtner notifications@github.com wrote:@aneillans thanks, ideally we should see if we can inject the expected IP addresses into the verification check... Maybe we could build a subnet check in this case?!

—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread.

[fichtner]

also in squid(4) now