[squid-users] Squid checking for both dstdomain and IP
Bruno de Paula Larini
bruno.larini at riosoft.com.br
Wed Jun 29 18:29:34 UTC 2022
> I do not recommend (ab)using ssl_bump rules for access control. When
> things go wrong, and they will, Squid may not reach your "ssl_bump
> terminate all" rule. Unlike http_access which is evaluated for
> virtually all incoming traffic, Squid evaluates ssl_bump rules only in
> some specific circumstances.
Is there a recommended way to deal with filtering in intercepted https
connections ? Or that's what Squid is able to do at the present?
(I'm guessing if there was, you already would have said it)
All reading material I was able to find on searches around the web
suggest using similar configurations.
Your explanation really helped me have a better understanding on how it
works though.
Thanks a lot.
Em 29/06/2022 12:57, Alex Rousskov escreveu:
> On 6/29/22 11:22, Bruno de Paula Larini wrote:
>>> The above rules allow abuse of sites matching allowed_sites (by
>>> proxying CONNECT traffic to any port on those sites).
>
>> Ok, maybe I'm lost. Any material on the internet I've read about
>> writing ACLs to allow access on Squid, including the Squid website,
>> follows the basic structure:
>> acl rule_name dstdomain "/path/to/file"
>> http_access allow rule_name
>> Which is exactly what I posted. Is there something wrong with that?
>
> You need to look at the http_access configuration as a whole. There
> may be nothing wrong with each http_access rule in isolation while the
> configuration is completely broken. For example, the following two
> configurations use identical set of rules. However, only one of them
> is correct:
>
> http_access allow goodRequests
> http_access deny all
>
> http_access deny all
> http_access allow goodRequests
>
> Your previous email did not contain critical http_access rules in your
> configuration, and I incorrectly assumed that you have no other
> http_access rules. Thank you for correcting that mistake:
>
>
>> http_access deny !Safe_ports
>> http_access deny CONNECT !SSL_ports
>>
>> http_access allow localhost manager
>> http_access deny manager
>>
>> http_access deny to_localhost
> >
>> http_access allow allowed_sites
>> http_access allow SSL_ports
> >
>> http_access allow localhost
>>
>> http_access deny all
>
> AFAICT, the above is your current http_access configuration. One of
> the (potential) problems I see is that you allow CONNECT tunnels to
> SSL ports of not-allowed sites.
>
>
>> But my reasoning behind that (and I'm probably wrong) is that only
>> the allowed sites would be permitted access, then "ssl_bump terminate
>> all" after splicing step2 would block other CONNECT attempts.
>
> I do not recommend (ab)using ssl_bump rules for access control. When
> things go wrong, and they will, Squid may not reach your "ssl_bump
> terminate all" rule. Unlike http_access which is evaluated for
> virtually all incoming traffic, Squid evaluates ssl_bump rules only in
> some specific circumstances.
>
>
>> In local tests it *apparently* worked as expected.
>
> Have you tested attacking your Squid with an (intercepted) TLS
> connection that goes to a prohibited server but contains an allowed
> site name in TLS SNI? AFAICT, Squid will allow and tunnel that
> connection. However, perhaps you do not consider this a valid attack
> in your environment.
>
>
>> But I really am uncertain if that's just wrong for what I'm trying to
>> achieve.
>
> No, your overall goals are reasonable/common.
>
>
> HTH,
>
> Alex.
>
>
>> Assuming 'http_access allow SSL_ports' is wrong, removing it takes me
>> back to the original problem:
>>
>> The following error was encountered while trying to retrieve
>> the URL: https://<ip_address>/*
>>
>> Access Denied.
>>
>> even if the 'dstdomain' hosted on that IP is allowed by the ACL.
>>
>> Based on the provided documentation, I understand that is in step2
>> that the Client Hello shows more information regarding the server
>> name, I tried peeking and then splicing on step3 but that also didn't
>> help.
>>
>> I'll put the full config here so anyone willing to help can better
>> understand it.
>>
>> Thanks!
>>
>> ### SQUID.CONF
>> #
>> # Recommended minimum configuration:
>> #
>>
>> # Example rule allowing access from your local networks.
>> # Adapt to list your (internal) IP networks from where browsing
>> # should be allowed
>> acl localnet src 0.0.0.1-0.255.255.255 # RFC 1122 "this" network (LAN)
>> acl localnet src 10.0.0.0/8 # RFC 1918 local private
>> network (LAN)
>> acl localnet src 100.64.0.0/10 # RFC 6598 shared address
>> space (CGN)
>> acl localnet src 169.254.0.0/16 # RFC 3927 link-local
>> (directly plugged) machines
>> acl localnet src 172.16.0.0/12 # RFC 1918 local private
>> network (LAN)
>> acl localnet src 192.168.0.0/16 # RFC 1918 local private
>> network (LAN)
>> acl localnet src fc00::/7 # RFC 4193 local private
>> network range
>> acl localnet src fe80::/10 # RFC 4291 link-local
>> (directly plugged) machines
>>
>> acl SSL_ports port 443
>> acl Safe_ports port 80 # http
>> acl Safe_ports port 21 # ftp
>> acl Safe_ports port 443 # https
>> acl Safe_ports port 70 # gopher
>> acl Safe_ports port 210 # wais
>> acl Safe_ports port 1025-65535 # unregistered ports
>> acl Safe_ports port 280 # http-mgmt
>> acl Safe_ports port 488 # gss-http
>> acl Safe_ports port 591 # filemaker
>> acl Safe_ports port 777 # multiling http
>>
>> #
>> # Recommended minimum Access Permission configuration:
>> #
>> # Deny requests to certain unsafe ports
>> http_access deny !Safe_ports
>>
>> # Deny CONNECT to other than secure SSL ports
>> http_access deny CONNECT !SSL_ports
>> # Only allow cachemgr access from localhost
>> http_access allow localhost manager
>> http_access deny manager
>>
>> # We strongly recommend the following be uncommented to protect innocent
>> # web applications running on the proxy server who think the only
>> # one who can access services on "localhost" is a local user
>> http_access deny to_localhost
>>
>> #
>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>> #
>>
>> debug_options ALL,0
>> access_log /var/log/squid/access.log
>>
>> acl allowed_sites dstdomain "/etc/squid/allowed-sites.txt"
>> acl spliced_sites ssl::server_name "/etc/squid/allowed-sites.txt"
>> http_access allow allowed_sites
>> # This probably should be removed, but it's making it work for this
>> test.
>> http_access allow SSL_ports
>>
>> acl step1 at_step SslBump1
>> acl step2 at_step SslBump2
>> ssl_bump peek step1 all
>> ssl_bump splice step2 spliced_sites
>> ssl_bump terminate all
>>
>> tls_outgoing_options capath=/etc/pki/tls/certs options=ALL
>> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
>> /var/lib/squid/ssl_db -M 8MB
>> sslcrtd_children 3
>>
>> #
>> #=============
>> #
>>
>> # Example rule allowing access from your local networks.
>> # Adapt localnet in the ACL section to list your (internal) IP networks
>> # from where browsing should be allowed
>> http_access allow localhost
>>
>> # And finally deny all other access to this proxy
>> http_access deny all
>>
>> # Squid normally listens to port 3128
>> http_port 192.168.10.10:8080
>> http_port 192.168.10.10:3128 intercept
>> https_port 192.168.10.10:3129 tls-cert=/etc/squid/ssl/squidCA.pem
>> tls-key=/etc/squid/ssl/squidCA.key ssl-bump intercept
>> generate-host-certificates=on dynamic_cert_mem_cache_size=8MB
>>
>> # Uncomment and adjust the following to add a disk cache directory.
>> #cache_dir ufs /var/spool/squid 100 16 256
>>
>> # Leave coredumps in the first cache dir
>> coredump_dir /var/spool/squid
>>
>> #
>> # Add any of your own refresh_pattern entries above these.
>> #
>> refresh_pattern ^ftp: 1440 20% 10080
>> refresh_pattern ^gopher: 1440 0% 1440
>> refresh_pattern -i (/cgi-bin/|\?) 0 0% 0
>> refresh_pattern . 0 20% 4320
>>
>>
>> Em 28/06/2022 17:05, Alex Rousskov escreveu:
>>> On 6/28/22 14:32, Bruno de Paula Larini wrote:
>>>
>>>> http_access allow allowed_sites
>>>> http_access allow SSL_ports
>>>
>>> The above rules allow abuse of sites matching allowed_sites (by
>>> proxying CONNECT traffic to any port on those sites). They also
>>> allow any traffic to SSL_ports of any site. In summary, they are not
>>> much better than allowing all traffic, creating an open proxy ripe
>>> for abuse.
>>>
>>> Most likely, Squid interpretation of http_access rules significantly
>>> differs from yours -- you probably thought the above rules achieve
>>> some other (desirable) effect. You may need to start from
>>> squid.conf.default rules and studying how http_access rules work in
>>> Squid. Once your interpretation matches Squid's you can advance to
>>> dealing with SslBump complexities; the above problems are not even
>>> related to SslBump.
>>>
>>> You may find the following page useful, but I realize that it has a
>>> lot of information irrelevant to your specific use case:
>>> https://wiki.squid-cache.org/SquidFaq/SquidAcl
>>>
>>>
>>> HTH,
>>>
>>> Alex.
>>>
>>>
>>> On 6/28/22 14:32, Bruno de Paula Larini wrote:
>>>
>>>> I was already following the provided link for reference.
>>>> It seems that splicing on step2 was correct, but in fact there were
>>>> other things that I missed.
>>>>
>>>> acl allowed_sites dstdomain "/etc/squid/allowed-sites.txt"
>>>> # Creates acl containing domain names for splice.
>>>> acl spliced_sites ssl::server_name "/etc/squid/allowed-sites.txt"
>>>> http_access allow allowed_sites
>>>> # This eliminates the browser error containing the IP from the
>>>> website.
>>>> # >> I don't know if there are caveats for allowing free access to
>>>> SSL_ports. <<
>>>> http_access allow SSL_ports
>>>>
>>>> acl step1 at_step SslBump1
>>>> acl step2 at_step SslBump2
>>>>
>>>> ssl_bump peek step1
>>>> ssl_bump splice step2 spliced_sites
>>>> # Same effect of 'deny all' for https websites.
>>>> ssl_bump terminate all
>>>> ...
>>>>
>>>> *Apparently* that does it.
>>>> If I stated anything wrong, please correct me.
>>>>
>>>> Cheers.
>>>>
>>>>
>>>> Em 28/06/2022 10:52, Alex Rousskov escreveu:
>>>>> On 6/28/22 08:08, Bruno de Paula Larini wrote:
>>>>>
>>>>>> I have a pretty simple configuration for website filtering
>>>>>> (intercepted) and ssl_bump, which follows below.
>>>>>> However, for some reason, it seems Squid resolves the website
>>>>>> domain address, then uses the IP to compare with the ACLs.
>>>>>
>>>>> Most likely, what is actually happening is that Squid does not
>>>>> have domain information during SslBump step1, and then gets that
>>>>> information during step2. Squid http_access rules apply to each
>>>>> SslBump step, so you have to write them accordingly.
>>>>>
>>>>> Available to Squid information and expected Squid behavior is
>>>>> documented for each step at the following wiki page. There are
>>>>> bugs in that algorithm _implementation_, but they are being fixed,
>>>>> and I am not aware of better docs:
>>>>> https://wiki.squid-cache.org/Features/SslPeekAndSplice#Processing_steps
>>>>>
>>>>>
>>>>>
>>>>> HTH,
>>>>>
>>>>> Alex.
>>>>>
>>>>>
>>>>>> As the IP is not included in the ACL, the access to the website
>>>>>> is denied.
>>>>>> Before that, it already checked for the domain name. I can tell
>>>>>> based on the error from the browser.
>>>>>> I'm using Squid version 5.5.
>>>>>>
>>>>>> For example, while trying to open https://repo.maven.apache.org/
>>>>>> (included in the allowed sites), the browser shows the error:
>>>>>>
>>>>>> The following error was encountered while trying to retrieve
>>>>>> the URL: https://199.232.192.215/*
>>>>>>
>>>>>> Access Denied.
>>>>>>
>>>>>> If I replace 'deny all' with 'allow all', the website will open
>>>>>> as expected.
>>>>>> Is there something wrong with my config? I have something similar
>>>>>> running and working on version 4.4 (unless I'm missing something).
>>>>>> I'm still only splicing for now.
>>>>>>
>>>>>> Thanks for the help!
>>>>>>
>>>>>>
>>>>>> ### SQUID.CONF
>>>>>> ...
>>>>>> #
>>>>>> # INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
>>>>>> #
>>>>>>
>>>>>> acl allowed_sites dstdomain "/etc/squid/allowed-sites.txt"
>>>>>> http_access allow allowed_sites
>>>>>>
>>>>>> acl step1 at_step SslBump1
>>>>>> ssl_bump peek step1
>>>>>> ssl_bump splice all
>>>>>>
>>>>>> tls_outgoing_options capath=/etc/pki/tls/certs options=ALL
>>>>>>
>>>>>> sslcrtd_program /usr/lib64/squid/security_file_certgen -s
>>>>>> /var/lib/squid/ssl_db -M 8MB
>>>>>> sslcrtd_children 3
>>>>>>
>>>>>> http_access allow localhost
>>>>>>
>>>>>> # And finally deny all other access to this proxy
>>>>>> http_access deny all
>>>>>>
>>>>>> # Squid normally listens to port 3128
>>>>>> http_port 192.168.10.10:8080
>>>>>> http_port 192.168.10.10:3128 intercept
>>>>>> https_port 192.168.10.10:3129 tls-cert=/etc/squid/ssl/squidCA.pem
>>>>>> tls-key=/etc/squid/ssl/squidCA.key ssl-bump intercept
>>>>>> generate-host-certificates=on dynamic_cert_mem_cache_size=8MB
>>>>>> ...
>>>>>>
>>>>>> ### IPTABLES
>>>>>> ...
>>>>>> iptables -t nat -A PREROUTING -i eth0 -s 192.168.10.0/24 -p tcp
>>>>>> --dport 80 -j REDIRECT --to-port 3128
>>>>>> iptables -t nat -A PREROUTING -i eth0 -s 192.168.10.0/24 -p tcp
>>>>>> --dport 443 -j REDIRECT --to-port 3129
>>>>>> ...
>>>
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
More information about the squid-users
mailing list