[squid-users] hostHeaderVerify with SNI in interception environments

[Andreas Weigel]

Hi,

I noticed that squid behaves differently with regard to checking the  
SNI of a (fake-)Connect request depending on the sslbump step a  
"splice" is performed. This is more or less a follow-up on " Squid  
spliced TLS handshake failing with chrome/ium fallback for certain  
servers".

If splicing at step2, hostHeaderVerify will be called twice, once with  
the initial TCP-only CONNECT and then again at step2, with SNI  
information from the TLS handshake's ClientHello. In certain  
unfortunate environments with DNS-resolvers configured differently  
between squid and its clients, this can lead to false positive  
"SECURITY ALERT: Host header forgery detected on..." and subsequential  
connection termination; this is also explained at  
https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery

If splicing at step3, however, hostHeaderVerify is not called again  
with the SNI, as the Connection is handled differently then (passed to  
FwdState and PeekingPeerConnector, as far as I can follow).

I was wondering if this could be considered a bug or if there is a  
rationale to change the behavior in the "peek at step2, splice at  
step3" scenario.

Kind regards,
Andreas