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

[Alex Rousskov]

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