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
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
