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=216.58.222.106:443
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
recommendations!
--
Atenciosamente / Sincerily,
Leonardo Rodrigues
Solutti Tecnologia
http://www.solutti.com.br
Minha armadilha de SPAM, NÃO mandem email
gertrudes@xxxxxxxxxxxxxx
My SPAMTRAP, do not email it
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
