[squid-users] issues with sslbump and "Host header forgery detected" warnings

Leonardo Rodrigues leolistas at solutti.com.br
Mon Nov 9 13:41:20 UTC 2020

Em 07/11/2020 22:19, Eliezer Croitor escreveu:
> Hey Leonardo,
> I assume The best solution for you is a simple SNI proxy.
> Squid does also that and you can try to debug this issue to make sure you understand what is wrong.
> It clearly states that Squid doesn't see this specific address: local=
> As the domain: chromesyncpasswords-pa.googleapis.com:443 "real" destination address.
> Maybe Alex or Amos remember the exact and relevant debug_options:
> https://wiki.squid-cache.org/KnowledgeBase/DebugSections
> I assume section 78 would be of help.
> debug_options ALL,1 78,3
> Is probably enough to discover what are the DNS responses and from where these are.
> On what OS are you running this Squid?

     Hi Eliezer,

     I have already tracked the DNS stuff and I could confirm that squid 
is resolving to a different IP address than the client is, despite both 
using the same DNS server. It only happens for hosts with multiple A 
addresses or CDN hostnames that changes IP very often (every 10 seconds 
for example). It's not a bug in that regards, absolutely not, the client 
connecting to a specific IP address and squid seeing another IP to that 
hostname caught on the TLS transaction is real.

     I'm running on CentOS 8 ... and after all, maybe these findings, 
I'm about to realize doing this kind of interception, even without the 
full decrypt part, is not trivial at all, despite it works flawlessly 
(and very easily) for "regular" hostnames which translates to a single 
IP and never changes it.

     Will study this a little more. Thanks for your observations and 


	Atenciosamente / Sincerily,
	Leonardo Rodrigues
	Solutti Tecnologia

	Minha armadilha de SPAM, NÃO mandem email
	gertrudes at solutti.com.br
	My SPAMTRAP, do not email it

More information about the squid-users mailing list