On 2/26/21 7:35 AM, Justin Michael Schwartzbeck wrote: >> Yes, many HTTPS transactions do not expose destination domain until it >> is too late to decide whether to bump them, and reverse DNS lookups are >> often unreliable. > I wonder why this would be. I suspect you assume that a forward DNS lookup (A or AAAA query) answer is always the "opposite" of a reverse DSN lookup (PTR query) answer. AFAIK, that is not how DNS is defined. From DNS point of view, each of those answers is totally independent -- there is no 1:1 or even 1:N mapping between them; the answers even come from different DNS zones! A caching DNS resolver would probably violate the DNS protocol if it uses a cached A or AAAA record to answer a PTR query. Disclaimer: I am not a DNS expert. > From my understanding, when you open a > browser and browse to www.google.com, the very > first thing that happens is you do a DNS resolution so that you know > what IP to send the CONNECT request and subsequent HTTPS records in the > first place. What happens depends on the browser and the proxy port: 1. For forward proxies: Some browsers will not do DNS lookups. They will send a CONNECT request to example.com, allowing Squid to do the DNS lookup. In this case, Squid dstdomain configured with a host name will work well. 2. For forward proxies: Some browsers do DNS lookups. They will send a CONNECT request to one of the returned IP addresses. 3. For interception proxies: All browsers do DNS lookups. They open a TCP connection to one of the returned IP addresses. In cases 2 and 3, Squid dstdomain will have to do a reverse DNS lookup (PTR query). In many cases, that lookup either fails or returns a different domain name than the domain the browser started with. HTH, Alex. > So we would have the IP already, and the hostname that was > looked up already in the DNS cache, right? Why wouldn't squid just be > able to reach in there, match the IP that DNS returned, and then pull > that hostname out to compare against the ACLs? > > On Thu, Feb 25, 2021 at 2:57 PM Alex Rousskov > <rousskov@xxxxxxxxxxxxxxxxxxxxxxx > <mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx>> wrote: > > On 2/25/21 2:07 PM, Justin Michael Schwartzbeck wrote: > > > I have thus far used dstdomain acl for bypassing ssl bump on sites > that > > we don't want to decrypt, like banking sites. It seems to work for > some > > sites, but not for others. > > Yes, many HTTPS transactions do not expose destination domain until it > is too late to decide whether to bump them, and reverse DNS lookups are > often unreliable. > > > > I was thinking about this, and it seems to me that if we are using the > > squid proxy with a dns server, we should be able to check the dns > cache > > for that IP, and find the associated hostname, and then match > against that. > > When you use dstdomain, Squid will do a (reverse) DNS query for you as > necessary (including DNS cache lookups) unless you specify a -n option > that is documented to disable all such operations. > > > In many cases, you should be using ssl::server_name instead of dstdomain > or dst ACL, but you may have to use a combination of various ACLs to > cover all the cases you care about. > > > HTH, > > Alex. > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
