Thanks for your answers Alex.
For case 1, I understand that should not be a problem, since squid is the one asking for DNS resolution.So if I have a local dns (maybe dnsmasq) that both squid and the user use, from what I understand I should be able to use squid's dns_nameservers directive to point to that DNS, and it should return fine since it is stored right there in the cache.
If the user is trying to use a different DNS server other than the local one, then fine, I will just decrypt their traffic as punishment. 😁
On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
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
