[squid-users] transparent proxy splice using dstdomain issue

[Amos Jeffries]

On 8/07/2015 1:54 a.m., S.Kirschner wrote:
> Amos Jeffries wrote
>> On 7/07/2015 11:45 p.m., S.Kirschner wrote:
>>> I think the issues exist because the reverse lookup dont got the anwser
>>> "sparkasse.de", but why it does not use the hostname from the dns request
>>> to
>>> the dns-server ?
>>
>> Because Squid is not a DNS server.
>>
>> The HTTP message details including URL where dstdomain comes from are
>> encrypted at the time you are trying to use the dstdomain ACL.
> 
> Yes but, in pfsense a dns server is installed, so on these host a dns server
> is running. Also i tried to use the google DNS 

Location of the DNS resolver has nothing to do with how Squid (or DNS)
operates.


> 
> Here now the entries from the cache.log
> 
> With sparkasse.de in /etc/hosts
> #2015/06/19 14:03:03.907 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking '212.34.69.3'
> #2015/06/19 14:03:03.907 kid1| DomainData.cc(113) match: aclMatchDomainList:
> '212.34.69.3' NOT found
> #2015/06/19 14:03:03.908 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking 'sparkasse.de'
> #2015/06/19 14:03:03.908 kid1| DomainData.cc(113) match: aclMatchDomainList:
> 'sparkasse.de' found

These are the rDNS host name in your hosts file for that IP.

In DNS hosts file entries are authoritative and override any gobal
registrations.


> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: bypass = 1
> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
> = 1
> #2015/06/19 14:03:03.908 kid1| Acl.cc(158) matches: checked: (ssl_bump
> rules) = 1
> 
> Without sparkasse.de in /etc/hosts
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking '212.34.69.3'
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
> '212.34.69.3' NOT found
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(108) match: aclMatchDomainList:
> checking 'rev-212.34.69.3.rev.izb.net'
> #2015/06/19 14:05:19.842 kid1| DomainData.cc(113) match: aclMatchDomainList:
> 'rev-212.34.69.3.rev.izb.net' NOT found

The real host name registered in global rDNS for that IP.

If I assume you configured Squid to use the pfsense DNS resolver. That
is the hostname it presents Squid with for that IP.

Note that domain name and host name are different concepts...
* one domain name DNS entry possibly points at multiple IPs, and
* multiple domain names can possibly point at one IP, but
* each IP rDNS points at exactly one host name.

So,
 212.34.69.3 is one of possibly many IPs for sparkasse.de.
 sparkasse.de is one of may names pointing at 212.34.69.3.


But, rev-212.34.69.3.rev.izb.net is the host name for 212.34.69.3.
 (which also means rev-212.34.69.3.rev.izb.net is the primary one of may
names pointing at 212.34.69.3).


Problem: since that IP has many domain names pointing at it. Which one
did the user lookup in *forward* DNS to get to that IP address?

 They could have as easily gone to https://rev-212.34.69.3.rev.izb.net/
as to https://sparkasse.de/ and the TCP connection would look identical
to Squid.


When dealing with HTTP (not encrypted) the answer is to look at the HTTP
message headers and see what they are requesting. dstdomain does that.

 BUT ... in HTTPS those headers are encrypted. And you are currently
deciding whether or not its appropriate to try and decrypt at all.

 Meaning the HTTP URL domain used by dstdomain is unavailable, and thus
dstdomain will not work properly.


> #2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: bypass = 0
> #2015/06/19 14:05:19.842 kid1| Acl.cc(158) matches: checked: (ssl_bump rule)
> = 0
> 

The proper solution for HTTPS is to use the correct ACL type
("ssl::server_name") designed for use in your situation. That uses the
non-encrypted TLS metadata, which provides the server hostname.


Despite popular myths TLS is not end-to-end (user-to-origin). It is
point-to-point (client-to-server) encryption, with maybe multiple hops
along the way.

The TLS server name metadata will only give you the hostname of the
server the client was contacting. With SNI it is usually (but no
guarantee) the domain name. When SNI is not available it's down to TLS
certificate SubjectName that could as easily be a TLS proxy or CDN
service in front of the real server(s) and in fact its usually states a
whole list of alternative names, and regex patterns!! of domain names,
which the cert might be used for.

The definitions for Site, Domain name, host name (note the space),
hostname, and X.509 SubjectName are different for good reasons. So are
the ACL definitions.

HTH
Amos