[squid-users] Squid ACL for bypassing ssl-bump

[Alex Rousskov]

On 2/26/21 12:45 PM, Justin Michael Schwartzbeck wrote:

> For case 2 and 3, what you are saying is that the browser is requesting
> the DNS lookup first, correct?

Correct, but that does not really matter.


> Hence the need for a reverse DNS from
> squid, since squid does not know at that point what domain the IP
> belongs to.

Squid "does not know" because all Squid gets is an IP address (in those
two cases).


> But they still had to query the DNS server, so that entry is
> in that DNS cache, and it should have the same domain as the lookup that
> the user entered.

DNS does not support what feels natural to you. You are thinking of a
name:IP cache entry that can be looked up by IP. That is a natural
model, but it does not match reality. DNS simply does not have an
interface that says "find me a name that maps to IP Y". DNS essentially
has only one interface: "find me what maps to name X". That is it! There
is just no way to ask a DNS server what name in its cache maps to an IP
address.

For reverse DNS lookups, the DNS client constructs an IP-based _name_ in
a special in-addr.arpa DNS zone and uses that name to query the DNS
server. For example, a "reverse" lookup for 127.0.0.1 is really a lookup
for the "1.0.0.127.in-addr.arpa" name. And that lookup follows all the
DNS rules about contacting authoritative servers for the zone, etc.; the
DNS server does not really "know" that what you really want is a cached
domain name for that 127.0.0.1 IP address.


> 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.

The IP may be stored, but it cannot be looked up using DNS.

Alex.


> On Fri, Feb 26, 2021 at 9:44 AM Alex Rousskov 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 <http://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 <http://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 at measurement-factory.com
>     <mailto:rousskov at measurement-factory.com>
>     > <mailto:rousskov at measurement-factory.com
>     <mailto:rousskov at measurement-factory.com>>> 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.
>     >
>