Strange Squid SSL Interception Behavior

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

Strange Squid SSL Interception Behavior

Mathew Brown
Hi,

I'm currently trying to configure transparent SSL proxying and running into a strange error that has me scratching my head for hours. I'm using Squid 4.11 (I also tried this with 4.12) with SSL support from here - http://squid411.diladele.com/ubuntu/ on Ubuntu 18.04.

I set up the necessary iptables forwarding ports and SSL certificates and it sometimes works (as you will see below).

My current configuration adds just the following to the default squid.conf file:

# INSERT YOUR OWN RULE(S) HERE TO ALLOW ACCESS FROM YOUR CLIENTS
#
include /etc/squid/conf.d/*

# 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 localnet
debug_options ALL,1, 33,2 2 28,9

http_port 3129 intercept
https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_cert/squid-ca.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
sslcrtd_program /usr/lib/squid/security_file_certgen -s /var/lib/ssl_db -M 4MB

acl whitelist ssl::server_name .httpbin.org
acl whitelist_http ssl::server_name .httpbin.org

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1
ssl_bump splice all

http_access allow whitelist
http_access allow whitelist_http

# And finally deny all other access to this proxy
http_access deny all

so the above configuration should allow anyone with access to the Squid proxy access to httpbin.org over both HTTP and HTTPS

when I try to access:

http://httpbin.org (not SSL)

it works

when I try to access:

https://httpbin.org

it fails as shown below (I'm running this on the Squid proxy machine itself):

$ wget https://httpbin.org
--2020-08-24 17:48:34--  https://httpbin.org/
Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet Widgits Pty Ltd,ST=Some-State,C=AU’:
  Self-signed certificate encountered.
To connect to httpbin.org insecurely, use `--no-check-certificate'.

$ wget https://httpbin.org --no-check-certificate
--2020-08-24 17:48:40--  https://httpbin.org/
Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet Widgits Pty Ltd,ST=Some-State,C=AU’:
  Self-signed certificate encountered.
HTTP request sent, awaiting response... 403 Forbidden
2020-08-24 17:48:40 ERROR 403: Forbidden.

looking at access.log shows:

1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT 54.236.246.173:443 - HIER_NONE/- -

for the first request (without the --no-check-certificate) and the following for the 2nd request (with the --no-check-certificate):

1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT 54.236.246.173:443 - HIER_NONE/- -
1598305812.300      2 192.168.123.214 NONE/403 3795 GET https://httpbin.org/ - HIER_NONE/- text/html

looking at cache.log shows:

# cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org

so it never matches on the httpbin.org

now, if I add the following line to my configuration:

http_access allow localnet

right before the:

http_access deny all

line it works and I see the following in access.log:

1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT 54.236.246.173:443 - HIER_NONE/- -
1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -

and I see the following in cache.log:

# cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking 'httpbin.org:443'
2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking 'httpbin.org'
2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match: 'httpbin.org' found

What's puzzling is why adding the 'allow localnet' line changes the ACL logic for .httpbin.org and why the original configuration does not work. Any ideas? Thanks

PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12



_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Antony Stone
On Tuesday 25 August 2020 at 00:21:31, Mathew Brown wrote:

> I set up the necessary iptables forwarding ports

Please show us what those iptables rules are.


Antony.

--
"It wouldn't be a good idea to talk about him behind his back in front of
him."

 - murble

                                                   Please reply to the list;
                                                         please *don't* CC me.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Alex Rousskov
In reply to this post by Mathew Brown
On 8/24/20 6:21 PM, Mathew Brown wrote:

> acl whitelist ssl::server_name .httpbin.org
> acl whitelist_http ssl::server_name .httpbin.org

> ssl_bump peek step1
> ssl_bump splice all

> http_access allow whitelist
> http_access allow whitelist_http
> http_access deny all

The rules above only allow CONNECT requests to .httpbin.org domains.

During step1, when Squid intercepts a TLS connection to an IP address of
an .httpbin.org domain, Squid http_access rules are applied to a (fake)
CONNECT request to the destination IP address. There are no domain names
at that TCP-level bumping stage. Thus, you place your Squid at the mercy
of reverse DSN lookups.

In my environment, reverse DNS does not work for httpbin.org the way you
may expect:

> $ host 54.236.246.173
> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.

The above AWS domain name does not match your whitelist ACLs, of course,
and, hence, the fake CONNECT request is denied. Denied requests are
bumped to deliver the error message. Bumped requests require
--no-check-certificate or other means of trusting Squid's CA certificate.

If you cannot explicitly allow CONNECT requests to httpbin.org IP
addresses (e.g., because they change too often), then consider allowing
CONNECT to safe ports at any address at step1. If you only intercept
connections to httpbin.org IPs, then you can probably relax your step1
http_access rules to allow all CONNECTs (to safe addresses).

There are many similar questions about allowing CONNECT to IP addresses
on this mailing list. You may be able to find more detailed advice or
instructions by searching for those mailing list threads.


HTH,

Alex.


> $ wget https://httpbin.org
> --2020-08-24 17:48:34--  https://httpbin.org/
> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet
> Widgits Pty Ltd,ST=Some-State,C=AU’:
>   Self-signed certificate encountered.
> To connect to httpbin.org insecurely, use `--no-check-certificate'.
>
> $ wget https://httpbin.org --no-check-certificate
> --2020-08-24 17:48:40--  https://httpbin.org/
> Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
> Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
> WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet
> Widgits Pty Ltd,ST=Some-State,C=AU’:
>   Self-signed certificate encountered.
> HTTP request sent, awaiting response... 403 Forbidden
> 2020-08-24 17:48:40 ERROR 403: Forbidden.
>
> looking at access.log shows:
>
> 1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
>
> for the first request (without the --no-check-certificate) and the
> following for the 2nd request (with the --no-check-certificate):
>
> 1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
> 1598305812.300      2 192.168.123.214 NONE/403 3795 GET
> https://httpbin.org/ - HIER_NONE/- text/html
>
> looking at cache.log shows:
>
> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>
> so it never matches on the httpbin.org
>
> now, if I add the following line to my configuration:
>
> http_access allow localnet
>
> right before the:
>
> http_access deny all
>
> line it works and I see the following in access.log:
>
> 1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
> 1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT
> httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -
>
> and I see the following in cache.log:
>
> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking
> 'httpbin.org:443'
> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking
> 'httpbin.org'
> 2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match:
> 'httpbin.org' found
>
> What's puzzling is why adding the 'allow localnet' line changes the ACL
> logic for .httpbin.org and why the original configuration does not work.
> Any ideas? Thanks
>
> PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12
>
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Mathew Brown
Thanks but even with the --no-check-certificate option and using a bump instead of splicing, it still fails as shown above unless I add the localnet rule. The question is: why does the same ACL line:

http_access allow whitelist

suddenly work when I add an unrelated ACL line after it (http_access allow localnet)? Why does it correctly determine the domain httpbin.org in the later case as shown by cache.log?

I updated my splice to a bump instead so my config looks like this:

acl whitelist ssl::server_name .httpbin.org
acl whitelist_http ssl::server_name .httpbin.org

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump peek step1
ssl_bump bump all

http_access allow whitelist
http_access allow whitelist_http

#http_access allow localnet
http_access deny all

and so it will bump all connections:

I then ran:

wget https://httpbin.org --no-check-certificate

and get the following (it fails):

cat access.log

1598316641.358      3 192.168.123.214 TCP_DENIED/200 0 CONNECT 3.220.112.94:443 - HIER_NONE/- -
1598316641.366      1 192.168.123.214 NONE/403 3789 GET https://httpbin.org/ - HIER_NONE/- text/html

cat cache.log | grep -i httpbin.org

2020/08/24 20:50:41.356 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:3.220.112.94 <>  .httpbin.org
2020/08/24 20:50:41.356 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:3.220.112.94 <>  .httpbin.org

while once I add the localnet rule:

http_access allow localnet

it succeeds and access.log looks like this:

1598316682.044    753 192.168.123.214 NONE/200 0 CONNECT 54.236.246.173:443 - ORIGINAL_DST/54.236.246.173 -
1598316682.329    260 192.168.123.214 TCP_REFRESH_MODIFIED/200 9936 GET https://httpbin.org/ - ORIGINAL_DST/54.236.246.173 text/html

and cache.log shows that it actually does the proper domain comparison:

cat cache.log | grep -i httpbin.org

2020/08/24 20:51:21.292 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 20:51:21.292 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
2020/08/24 20:51:22.071 kid1| 28,3| RegexData.cc(43) match: checking 'https://httpbin.org/'
2020/08/24 20:51:22.071 kid1| 28,4| ServerName.cc(82) check_cert_domain: Verifying certificate name/subjectAltName httpbin.org
2020/08/24 20:51:22.071 kid1| 28,3| ServerName.cc(42) match: checking 'httpbin.org'
2020/08/24 20:51:22.071 kid1| 28,7| ServerName.cc(32) aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
2020/08/24 20:51:22.071 kid1| 28,3| ServerName.cc(47) match: 'httpbin.org' found

From my understanding, Squid should perform the exact same steps in both cases BUT then allow the connection because of the localnet ACL line that it sees right before the deny all line, not because it suddenly was able to match httpbin.org using a domain compare as shown by the debug logs. What am I missing?

Even if I add a peek at step2, the behavior is still the same for the first scenario although I no longer need to use --no-check-certificate in the 2nd scenario (where I whitelist localnet)

PS. I'm using the current iptable rules and making the wget call from a normal user account (so neither root or proxy):

iptables -t nat -A OUTPUT -p tcp -m tcp --dport 80 -m owner --uid-owner root -j RETURN
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 80 -m owner --uid-owner proxy -j RETURN
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 3129
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 443 -m owner --uid-owner root -j RETURN
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 443 -m owner --uid-owner proxy -j RETURN
iptables -t nat -A OUTPUT -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 3130



From: Alex Rousskov <[hidden email]>
Sent: Tuesday, August 25, 2020 8:41 AM
To: Mathew Brown <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [squid-users] Strange Squid SSL Interception Behavior
 
On 8/24/20 6:21 PM, Mathew Brown wrote:

> acl whitelist ssl::server_name .httpbin.org
> acl whitelist_http ssl::server_name .httpbin.org

> ssl_bump peek step1
> ssl_bump splice all

> http_access allow whitelist
> http_access allow whitelist_http
> http_access deny all

The rules above only allow CONNECT requests to .httpbin.org domains.

During step1, when Squid intercepts a TLS connection to an IP address of
an .httpbin.org domain, Squid http_access rules are applied to a (fake)
CONNECT request to the destination IP address. There are no domain names
at that TCP-level bumping stage. Thus, you place your Squid at the mercy
of reverse DSN lookups.

In my environment, reverse DNS does not work for httpbin.org the way you
may expect:

> $ host 54.236.246.173
> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.

The above AWS domain name does not match your whitelist ACLs, of course,
and, hence, the fake CONNECT request is denied. Denied requests are
bumped to deliver the error message. Bumped requests require
--no-check-certificate or other means of trusting Squid's CA certificate.

If you cannot explicitly allow CONNECT requests to httpbin.org IP
addresses (e.g., because they change too often), then consider allowing
CONNECT to safe ports at any address at step1. If you only intercept
connections to httpbin.org IPs, then you can probably relax your step1
http_access rules to allow all CONNECTs (to safe addresses).

There are many similar questions about allowing CONNECT to IP addresses
on this mailing list. You may be able to find more detailed advice or
instructions by searching for those mailing list threads.


HTH,

Alex.


> $ wget https://httpbin.org
> --2020-08-24 17:48:34--  https://httpbin.org/
> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet
> Widgits Pty Ltd,ST=Some-State,C=AU’:
>   Self-signed certificate encountered.
> To connect to httpbin.org insecurely, use `--no-check-certificate'.
>
> $ wget https://httpbin.org --no-check-certificate
> --2020-08-24 17:48:40--  https://httpbin.org/
> Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
> Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
> WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet
> Widgits Pty Ltd,ST=Some-State,C=AU’:
>   Self-signed certificate encountered.
> HTTP request sent, awaiting response... 403 Forbidden
> 2020-08-24 17:48:40 ERROR 403: Forbidden.
>
> looking at access.log shows:
>
> 1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
>
> for the first request (without the --no-check-certificate) and the
> following for the 2nd request (with the --no-check-certificate):
>
> 1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
> 1598305812.300      2 192.168.123.214 NONE/403 3795 GET
> https://httpbin.org/ - HIER_NONE/- text/html
>
> looking at cache.log shows:
>
> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>
> so it never matches on the httpbin.org
>
> now, if I add the following line to my configuration:
>
> http_access allow localnet
>
> right before the:
>
> http_access deny all
>
> line it works and I see the following in access.log:
>
> 1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT
> 54.236.246.173:443 - HIER_NONE/- -
> 1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT
> httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -
>
> and I see the following in cache.log:
>
> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
> 2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking
> 'httpbin.org:443'
> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking
> 'httpbin.org'
> 2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32)
> aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match:
> 'httpbin.org' found
>
> What's puzzling is why adding the 'allow localnet' line changes the ACL
> logic for .httpbin.org and why the original configuration does not work.
> Any ideas? Thanks
>
> PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12
>
>
>
> _______________________________________________
> squid-users mailing list
> [hidden email]
> http://lists.squid-cache.org/listinfo/squid-users
>


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Amos Jeffries
Administrator
On 25/08/20 1:09 pm, Mathew Brown wrote:

> Thanks but even with the --no-check-certificate option and using a bump
> instead of splicing, it still fails as shown above unless I add the
> localnet rule. The question is: why does the same ACL line:
>
> http_access allow whitelist
>
> suddenly work when I add an unrelated ACL line after it (http_access
> allow localnet)? Why does it correctly determine the domain httpbin.org
> in the later case as shown by cache.log?
>

The email from Alex Alex you are replying to already answers both those
questions completely.


> *From:* Alex Rousskov
...

>
> The rules above only allow CONNECT requests to .httpbin.org domains.
>
> During step1, when Squid intercepts a TLS connection to an IP address of
> an .httpbin.org domain, Squid http_access rules are applied to a (fake)
> CONNECT request to the destination IP address. There are no domain names
> at that TCP-level bumping stage. Thus, you place your Squid at the mercy
> of reverse DSN lookups.
>
> In my environment, reverse DNS does not work for httpbin.org the way you
> may expect:
>
>> $ host 54.236.246.173
>> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.
>
> The above AWS domain name does not match your whitelist ACLs, of course,
> and, hence, the fake CONNECT request is denied.


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Alex Rousskov
In reply to this post by Mathew Brown
On 8/24/20 9:09 PM, Mathew Brown wrote:
> Thanks but even with the --no-check-certificate option and using a bump
> instead of splicing, it still fails as shown above unless I add the
> localnet rule. The question is: why does the same ACL line:

> http_access allow whitelist

> suddenly work when I add an unrelated ACL line after it?

You are misinterpreting the outcome of the test. That whitelist
http_access line did not work (well) for fake CONNECTs before and does
not start working (well) after another http_access rule is added. It is
the added rule that "starts working" instead!

Most ACL-driven directives, including http_access, cannot be correctly
interpreted at single-ACL, single-line, or single-rule scope. You must
consider _all_ rules for a given directive to correctly predict the
outcome of that directive evaluation. When you add a rule, the outcome
of the directive evaluation may change if the previous set of rules did
not match and the added rule does match. The latter is exactly what
happens in your "add an unrelated ACL" test case.

For completeness sake: When no http_access rules match, Squid applies
the action (allow or deny) that is the opposite of the last configured
http_access rule action. If no http_access rules were configured at all,
Squid denies.


There is similar (albeit a bit incomplete) information in the (arguably
misplaced) FAQ section at
https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists


> From my understanding, Squid should perform the exact same steps in both
> cases BUT then allow the connection because of the localnet ACL line
> that it sees right before the deny all line, not because it suddenly was
> able to match httpbin.org using a domain compare as shown by the debug
> logs. What am I missing?

You may also be missing the fact that http_access directive is applied
several times for one wget execution, once at every SslBump step. The
information available to Squid at each SslBump step differs.
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Domain-based ACL matches you see in the second test log probably do not
exist in the first test because Squid does not get far enough during the
first test -- Squid denies the fake CONNECT (and bumps the connection)
at step1, when no domain information is available yet.


HTH,

Alex.


> ------------------------------------------------------------------------
> *From:* Alex Rousskov <[hidden email]>
> *Sent:* Tuesday, August 25, 2020 8:41 AM
> *To:* Mathew Brown <[hidden email]>;
> [hidden email] <[hidden email]>
> *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior
>  
> On 8/24/20 6:21 PM, Mathew Brown wrote:
>
>> acl whitelist ssl::server_name .httpbin.org
>> acl whitelist_http ssl::server_name .httpbin.org
>
>> ssl_bump peek step1
>> ssl_bump splice all
>
>> http_access allow whitelist
>> http_access allow whitelist_http
>> http_access deny all
>
> The rules above only allow CONNECT requests to .httpbin.org domains.
>
> During step1, when Squid intercepts a TLS connection to an IP address of
> an .httpbin.org domain, Squid http_access rules are applied to a (fake)
> CONNECT request to the destination IP address. There are no domain names
> at that TCP-level bumping stage. Thus, you place your Squid at the mercy
> of reverse DSN lookups.
>
> In my environment, reverse DNS does not work for httpbin.org the way you
> may expect:
>
>> $ host 54.236.246.173
>> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.
>
> The above AWS domain name does not match your whitelist ACLs, of course,
> and, hence, the fake CONNECT request is denied. Denied requests are
> bumped to deliver the error message. Bumped requests require
> --no-check-certificate or other means of trusting Squid's CA certificate.
>
> If you cannot explicitly allow CONNECT requests to httpbin.org IP
> addresses (e.g., because they change too often), then consider allowing
> CONNECT to safe ports at any address at step1. If you only intercept
> connections to httpbin.org IPs, then you can probably relax your step1
> http_access rules to allow all CONNECTs (to safe addresses).
>
> There are many similar questions about allowing CONNECT to IP addresses
> on this mailing list. You may be able to find more detailed advice or
> instructions by searching for those mailing list threads.
>
>
> HTH,
>
> Alex.
>
>
>> $ wget https://httpbin.org
>> --2020-08-24 17:48:34--  https://httpbin.org/
>> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
>> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
>> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>   Self-signed certificate encountered.
>> To connect to httpbin.org insecurely, use `--no-check-certificate'.
>>
>> $ wget https://httpbin.org --no-check-certificate
>> --2020-08-24 17:48:40--  https://httpbin.org/
>> Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
>> Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
>> WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>   Self-signed certificate encountered.
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2020-08-24 17:48:40 ERROR 403: Forbidden.
>>
>> looking at access.log shows:
>>
>> 1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>>
>> for the first request (without the --no-check-certificate) and the
>> following for the 2nd request (with the --no-check-certificate):
>>
>> 1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>> 1598305812.300      2 192.168.123.214 NONE/403 3795 GET
>> https://httpbin.org/ - HIER_NONE/- text/html
>>
>> looking at cache.log shows:
>>
>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>
>> so it never matches on the httpbin.org
>>
>> now, if I add the following line to my configuration:
>>
>> http_access allow localnet
>>
>> right before the:
>>
>> http_access deny all
>>
>> line it works and I see the following in access.log:
>>
>> 1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>> 1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT
>> httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -
>>
>> and I see the following in cache.log:
>>
>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking
>> 'httpbin.org:443'
>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking
>> 'httpbin.org'
>> 2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match:
>> 'httpbin.org' found
>>
>> What's puzzling is why adding the 'allow localnet' line changes the ACL
>> logic for .httpbin.org and why the original configuration does not work.
>> Any ideas? Thanks
>>
>> PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12
>>
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Mathew Brown
Thank you Alex for your patience and clarification. After reading your explanation and based on my limited understanding, I was able to get the following to work:

...
acl whitelist ssl::server_name .httpbin.org

...
http_access deny CONNECT !SSL_ports
http_access allow localnet CONNECT

acl step1 at_step SslBump1
ssl_bump peek step1
ssl_bump terminate !whitelist
ssl_bump splice all

The above allows access only to httpbin.org and no other domains

If I understand correctly, the original issue is that the CONNECT has to be allowed explicitly and it was not (I just had the typical DENY for non SSL ports) and because of this, it was not be able to proceed in the SSL bumping path. Is my understanding correct? Thanks



From: Alex Rousskov <[hidden email]>
Sent: Tuesday, August 25, 2020 11:24 PM
To: Mathew Brown <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [squid-users] Strange Squid SSL Interception Behavior
 
On 8/24/20 9:09 PM, Mathew Brown wrote:
> Thanks but even with the --no-check-certificate option and using a bump
> instead of splicing, it still fails as shown above unless I add the
> localnet rule. The question is: why does the same ACL line:

> http_access allow whitelist

> suddenly work when I add an unrelated ACL line after it?

You are misinterpreting the outcome of the test. That whitelist
http_access line did not work (well) for fake CONNECTs before and does
not start working (well) after another http_access rule is added. It is
the added rule that "starts working" instead!

Most ACL-driven directives, including http_access, cannot be correctly
interpreted at single-ACL, single-line, or single-rule scope. You must
consider _all_ rules for a given directive to correctly predict the
outcome of that directive evaluation. When you add a rule, the outcome
of the directive evaluation may change if the previous set of rules did
not match and the added rule does match. The latter is exactly what
happens in your "add an unrelated ACL" test case.

For completeness sake: When no http_access rules match, Squid applies
the action (allow or deny) that is the opposite of the last configured
http_access rule action. If no http_access rules were configured at all,
Squid denies.


There is similar (albeit a bit incomplete) information in the (arguably
misplaced) FAQ section at
https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists


> From my understanding, Squid should perform the exact same steps in both
> cases BUT then allow the connection because of the localnet ACL line
> that it sees right before the deny all line, not because it suddenly was
> able to match httpbin.org using a domain compare as shown by the debug
> logs. What am I missing?

You may also be missing the fact that http_access directive is applied
several times for one wget execution, once at every SslBump step. The
information available to Squid at each SslBump step differs.
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Domain-based ACL matches you see in the second test log probably do not
exist in the first test because Squid does not get far enough during the
first test -- Squid denies the fake CONNECT (and bumps the connection)
at step1, when no domain information is available yet.


HTH,

Alex.


> ------------------------------------------------------------------------
> *From:* Alex Rousskov <[hidden email]>
> *Sent:* Tuesday, August 25, 2020 8:41 AM
> *To:* Mathew Brown <[hidden email]>;
> [hidden email] <[hidden email]>
> *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior
>  
> On 8/24/20 6:21 PM, Mathew Brown wrote:
>
>> acl whitelist ssl::server_name .httpbin.org
>> acl whitelist_http ssl::server_name .httpbin.org
>
>> ssl_bump peek step1
>> ssl_bump splice all
>
>> http_access allow whitelist
>> http_access allow whitelist_http
>> http_access deny all
>
> The rules above only allow CONNECT requests to .httpbin.org domains.
>
> During step1, when Squid intercepts a TLS connection to an IP address of
> an .httpbin.org domain, Squid http_access rules are applied to a (fake)
> CONNECT request to the destination IP address. There are no domain names
> at that TCP-level bumping stage. Thus, you place your Squid at the mercy
> of reverse DSN lookups.
>
> In my environment, reverse DNS does not work for httpbin.org the way you
> may expect:
>
>> $ host 54.236.246.173
>> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.
>
> The above AWS domain name does not match your whitelist ACLs, of course,
> and, hence, the fake CONNECT request is denied. Denied requests are
> bumped to deliver the error message. Bumped requests require
> --no-check-certificate or other means of trusting Squid's CA certificate.
>
> If you cannot explicitly allow CONNECT requests to httpbin.org IP
> addresses (e.g., because they change too often), then consider allowing
> CONNECT to safe ports at any address at step1. If you only intercept
> connections to httpbin.org IPs, then you can probably relax your step1
> http_access rules to allow all CONNECTs (to safe addresses).
>
> There are many similar questions about allowing CONNECT to IP addresses
> on this mailing list. You may be able to find more detailed advice or
> instructions by searching for those mailing list threads.
>
>
> HTH,
>
> Alex.
>
>
>> $ wget https://httpbin.org
>> --2020-08-24 17:48:34--  https://httpbin.org/
>> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
>> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
>> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>   Self-signed certificate encountered.
>> To connect to httpbin.org insecurely, use `--no-check-certificate'.
>>
>> $ wget https://httpbin.org --no-check-certificate
>> --2020-08-24 17:48:40--  https://httpbin.org/
>> Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
>> Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
>> WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>   Self-signed certificate encountered.
>> HTTP request sent, awaiting response... 403 Forbidden
>> 2020-08-24 17:48:40 ERROR 403: Forbidden.
>>
>> looking at access.log shows:
>>
>> 1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>>
>> for the first request (without the --no-check-certificate) and the
>> following for the 2nd request (with the --no-check-certificate):
>>
>> 1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>> 1598305812.300      2 192.168.123.214 NONE/403 3795 GET
>> https://httpbin.org/ - HIER_NONE/- text/html
>>
>> looking at cache.log shows:
>>
>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>
>> so it never matches on the httpbin.org
>>
>> now, if I add the following line to my configuration:
>>
>> http_access allow localnet
>>
>> right before the:
>>
>> http_access deny all
>>
>> line it works and I see the following in access.log:
>>
>> 1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT
>> 54.236.246.173:443 - HIER_NONE/- -
>> 1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT
>> httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -
>>
>> and I see the following in cache.log:
>>
>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>> 2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking
>> 'httpbin.org:443'
>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking
>> 'httpbin.org'
>> 2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32)
>> aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match:
>> 'httpbin.org' found
>>
>> What's puzzling is why adding the 'allow localnet' line changes the ACL
>> logic for .httpbin.org and why the original configuration does not work.
>> Any ideas? Thanks
>>
>> PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12
>>
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> [hidden email]
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>


_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Alex Rousskov
On 8/25/20 6:15 PM, Mathew Brown wrote:

> http_access deny CONNECT !SSL_ports
> http_access allow localnet CONNECT

> ssl_bump peek step1
> ssl_bump terminate !whitelist
> ssl_bump splice all


FYI: The above ssl_bump rules can be rewritten to avoid negation (which
can have surprising/unwanted effects in error cases):

  ssl_bump peek step1
  ssl_bump splice whitelist
  ssl_bump terminate all


> The above allows access only to httpbin.org and no other domains

Yes, in cases where "to httpbin.org" can be determined based on TCP
client and TLS client handshake information. For example, if reverse DNS
lookup do not work well, then the above rules will terminate TLS clients
that omit TLS SNI information or that send fake/encrypted SNI, even if
those clients are trying to establish a TLS connection with one of the
httpbin.org servers.

My example is not meant as a criticism of your configuration. Only as an
additional information about that configuration effects.


> If I understand correctly, the original issue is that the CONNECT has
> to be allowed explicitly and it was not and because of this, it was
> not be able to proceed in the SSL bumping path. Is my understanding
> correct?

Just one minor correction/clarification: It is best to think of Squid
configuration as if _everything_ has to be allowed explicitly (rather
than that something is allowed implicitly and some exceptional cases
need special rules).

For example, AFAICT, your current configuration allows local [fake]
CONNECTs to safe ports (and nothing else). That access policy is fine if
it matches your intent. The policy will stop working if you decide to
bump and forward HTTPS traffic or forward plain text HTTP requests.


HTH,

Alex.


> ------------------------------------------------------------------------
> *From:* Alex Rousskov <[hidden email]>
> *Sent:* Tuesday, August 25, 2020 11:24 PM
> *To:* Mathew Brown <[hidden email]>;
> [hidden email] <[hidden email]>
> *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior
>  
> On 8/24/20 9:09 PM, Mathew Brown wrote:
>> Thanks but even with the --no-check-certificate option and using a bump
>> instead of splicing, it still fails as shown above unless I add the
>> localnet rule. The question is: why does the same ACL line:
>
>> http_access allow whitelist
>
>> suddenly work when I add an unrelated ACL line after it?
>
> You are misinterpreting the outcome of the test. That whitelist
> http_access line did not work (well) for fake CONNECTs before and does
> not start working (well) after another http_access rule is added. It is
> the added rule that "starts working" instead!
>
> Most ACL-driven directives, including http_access, cannot be correctly
> interpreted at single-ACL, single-line, or single-rule scope. You must
> consider _all_ rules for a given directive to correctly predict the
> outcome of that directive evaluation. When you add a rule, the outcome
> of the directive evaluation may change if the previous set of rules did
> not match and the added rule does match. The latter is exactly what
> happens in your "add an unrelated ACL" test case.
>
> For completeness sake: When no http_access rules match, Squid applies
> the action (allow or deny) that is the opposite of the last configured
> http_access rule action. If no http_access rules were configured at all,
> Squid denies.
>
>
> There is similar (albeit a bit incomplete) information in the (arguably
> misplaced) FAQ section at
> https://wiki.squid-cache.org/SquidFaq/SquidAcl#Access_Lists
>
>
>> From my understanding, Squid should perform the exact same steps in both
>> cases BUT then allow the connection because of the localnet ACL line
>> that it sees right before the deny all line, not because it suddenly was
>> able to match httpbin.org using a domain compare as shown by the debug
>> logs. What am I missing?
>
> You may also be missing the fact that http_access directive is applied
> several times for one wget execution, once at every SslBump step. The
> information available to Squid at each SslBump step differs.
> https://wiki.squid-cache.org/Features/SslPeekAndSplice
>
> Domain-based ACL matches you see in the second test log probably do not
> exist in the first test because Squid does not get far enough during the
> first test -- Squid denies the fake CONNECT (and bumps the connection)
> at step1, when no domain information is available yet.
>
>
> HTH,
>
> Alex.
>
>
>> ------------------------------------------------------------------------
>> *From:* Alex Rousskov <[hidden email]>
>> *Sent:* Tuesday, August 25, 2020 8:41 AM
>> *To:* Mathew Brown <[hidden email]>;
>> [hidden email] <[hidden email]>
>> *Subject:* Re: [squid-users] Strange Squid SSL Interception Behavior
>>  
>> On 8/24/20 6:21 PM, Mathew Brown wrote:
>>
>>> acl whitelist ssl::server_name .httpbin.org
>>> acl whitelist_http ssl::server_name .httpbin.org
>>
>>> ssl_bump peek step1
>>> ssl_bump splice all
>>
>>> http_access allow whitelist
>>> http_access allow whitelist_http
>>> http_access deny all
>>
>> The rules above only allow CONNECT requests to .httpbin.org domains.
>>
>> During step1, when Squid intercepts a TLS connection to an IP address of
>> an .httpbin.org domain, Squid http_access rules are applied to a (fake)
>> CONNECT request to the destination IP address. There are no domain names
>> at that TCP-level bumping stage. Thus, you place your Squid at the mercy
>> of reverse DSN lookups.
>>
>> In my environment, reverse DNS does not work for httpbin.org the way you
>> may expect:
>>
>>> $ host 54.236.246.173
>>> 173.246.236.54.in-addr.arpa domain name pointer ec2-54-236-246-173.compute-1.amazonaws.com.
>>
>> The above AWS domain name does not match your whitelist ACLs, of course,
>> and, hence, the fake CONNECT request is denied. Denied requests are
>> bumped to deliver the error message. Bumped requests require
>> --no-check-certificate or other means of trusting Squid's CA certificate.
>>
>> If you cannot explicitly allow CONNECT requests to httpbin.org IP
>> addresses (e.g., because they change too often), then consider allowing
>> CONNECT to safe ports at any address at step1. If you only intercept
>> connections to httpbin.org IPs, then you can probably relax your step1
>> http_access rules to allow all CONNECTs (to safe addresses).
>>
>> There are many similar questions about allowing CONNECT to IP addresses
>> on this mailing list. You may be able to find more detailed advice or
>> instructions by searching for those mailing list threads.
>>
>>
>> HTH,
>>
>> Alex.
>>
>>
>>> $ wget https://httpbin.org
>>> --2020-08-24 17:48:34--  https://httpbin.org/
>>> Resolving httpbin.org (httpbin.org)... 54.236.246.173, 3.220.112.94
>>> Connecting to httpbin.org (httpbin.org)|54.236.246.173|:443... connected.
>>> ERROR: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>>   Self-signed certificate encountered.
>>> To connect to httpbin.org insecurely, use `--no-check-certificate'.
>>>
>>> $ wget https://httpbin.org --no-check-certificate
>>> --2020-08-24 17:48:40--  https://httpbin.org/
>>> Resolving httpbin.org (httpbin.org)... 3.220.112.94, 54.236.246.173
>>> Connecting to httpbin.org (httpbin.org)|3.220.112.94|:443... connected.
>>> WARNING: cannot verify httpbin.org's certificate, issued by ‘O=Internet
>>> Widgits Pty Ltd,ST=Some-State,C=AU’:
>>>   Self-signed certificate encountered.
>>> HTTP request sent, awaiting response... 403 Forbidden
>>> 2020-08-24 17:48:40 ERROR 403: Forbidden.
>>>
>>> looking at access.log shows:
>>>
>>> 1598305800.974      2 192.168.123.214 TCP_DENIED/200 0 CONNECT
>>> 54.236.246.173:443 - HIER_NONE/- -
>>>
>>> for the first request (without the --no-check-certificate) and the
>>> following for the 2nd request (with the --no-check-certificate):
>>>
>>> 1598305812.292      3 192.168.123.214 TCP_DENIED/200 0 CONNECT
>>> 54.236.246.173:443 - HIER_NONE/- -
>>> 1598305812.300      2 192.168.123.214 NONE/403 3795 GET
>>> https://httpbin.org/ - HIER_NONE/- text/html
>>>
>>> looking at cache.log shows:
>>>
>>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>> 2020/08/24 17:50:00.972 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>> 2020/08/24 17:50:12.290 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>>
>>> so it never matches on the httpbin.org
>>>
>>> now, if I add the following line to my configuration:
>>>
>>> http_access allow localnet
>>>
>>> right before the:
>>>
>>> http_access deny all
>>>
>>> line it works and I see the following in access.log:
>>>
>>> 1598305979.004      4 192.168.123.214 NONE/200 0 CONNECT
>>> 54.236.246.173:443 - HIER_NONE/- -
>>> 1598305980.016   1012 192.168.123.214 TCP_TUNNEL/200 15370 CONNECT
>>> httpbin.org:443 - ORIGINAL_DST/54.236.246.173 -
>>>
>>> and I see the following in cache.log:
>>>
>>> # cat /var/log/squid/cache.log  | grep -i "28" | grep -i httpbin
>>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>> 2020/08/24 17:52:59.000 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:54.236.246.173 <>  .httpbin.org
>>> 2020/08/24 17:52:59.005 kid1| 28,3| RegexData.cc(43) match: checking
>>> 'httpbin.org:443'
>>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(42) match: checking
>>> 'httpbin.org'
>>> 2020/08/24 17:52:59.005 kid1| 28,7| ServerName.cc(32)
>>> aclHostDomainCompare: Match:httpbin.org <>  .httpbin.org
>>> 2020/08/24 17:52:59.005 kid1| 28,3| ServerName.cc(47) match:
>>> 'httpbin.org' found
>>>
>>> What's puzzling is why adding the 'allow localnet' line changes the ACL
>>> logic for .httpbin.org and why the original configuration does not work.
>>> Any ideas? Thanks
>>>
>>> PS. I reproduced the exact same scenario on Ubuntu 20.04 with Squid 4.12
>>>
>>>
>>>
>>> _______________________________________________
>>> squid-users mailing list
>>> [hidden email]
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>
>

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Amos Jeffries
Administrator
On 26/08/20 10:39 am, Alex Rousskov wrote:
> On 8/25/20 6:15 PM, Mathew Brown wrote:
>
>> http_access deny CONNECT !SSL_ports
>> http_access allow localnet CONNECT
>

AIUI, this would be better if it works:

 http_access deny CONNECT !SSL_ports
 http_access allow CONNECT step1


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Mathew Brown
Thank you Alex + Amos :) You've really helped clarify things. I had a final question regarding this setup. Does this configuration only look at the client side part of the SNI request or also the server certificate. If it only looks at the client-side, how would I tell it to look at the server response as well? Thanks.

From: squid-users <[hidden email]> on behalf of Amos Jeffries <[hidden email]>
Sent: Wednesday, August 26, 2020 2:03 PM
To: [hidden email] <[hidden email]>
Subject: Re: [squid-users] Strange Squid SSL Interception Behavior
 
On 26/08/20 10:39 am, Alex Rousskov wrote:
> On 8/25/20 6:15 PM, Mathew Brown wrote:
>
>> http_access deny CONNECT !SSL_ports
>> http_access allow localnet CONNECT
>

AIUI, this would be better if it works:

 http_access deny CONNECT !SSL_ports
 http_access allow CONNECT step1


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Amos Jeffries
Administrator
On 26/08/20 11:03 pm, Mathew Brown wrote:
> Thank you Alex + Amos :) You've really helped clarify things. I had a
> final question regarding this setup. Does this configuration only look
> at the client side part of the SNI request or also the server
> certificate. If it only looks at the client-side, how would I tell it to
> look at the server response as well? Thanks.


SSL-Bump step 1 decides whether to look at the client handshake details.

Step 2 decides whether to look at the server handshake details.

Step 3 decides what to do given all available info from both handshakes.

The process is all described at
<https://wiki.squid-cache.org/Features/SslPeekAndSplice>


Amos
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Alex Rousskov
On 8/26/20 9:13 AM, Amos Jeffries wrote:
> On 26/08/20 11:03 pm, Mathew Brown wrote:
>> Thank you Alex + Amos :) You've really helped clarify things. I had a
>> final question regarding this setup. Does this configuration only look
>> at the client side part of the SNI request or also the server
>> certificate.

>> acl whitelist ssl::server_name .httpbin.org
>>
>> http_access deny CONNECT !SSL_ports
>> http_access allow localnet CONNECT
>>
>> ssl_bump peek step1
>> ssl_bump splice whitelist
>> ssl_bump terminate all


The above ssl_bump configuration ignores the TCP client information
(during step1) and looks at TLS client information (during the next step
-- step2). With this configuration, Squid will not see the server
certificate at all.


>> If it only looks at the client-side, how would I tell it to
>> look at the server response as well?

If you want Squid to consider the server certificate as well (during
step3), replace "step1" with "all". See ssl::server_name ACL for the
documentation of what "as well" really means in this context. Its
complicated.


> The process is all described at
> https://wiki.squid-cache.org/Features/SslPeekAndSplice

Yes, and also see the documentation for the ssl::server_name ACL. In
modern Squids, you can control what information that ACL is using.


BTW, I just realized that my earlier statements about reverse DNS
lookups were misleading: The ssl::server_name ACL does not do any DNS
lookups. When given an unresolved IP address, that ACL will usually
mismatch .httpbin.org (regardless of whether the reverse lookup would
have returned a matching domain name).


HTH,

Alex.
_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users
Reply | Threaded
Open this post in threaded view
|

Re: Strange Squid SSL Interception Behavior

Mathew Brown
Thanks Alex

From: Alex Rousskov <[hidden email]>
Sent: Wednesday, August 26, 2020 11:54 PM
To: Mathew Brown <[hidden email]>; [hidden email] <[hidden email]>
Subject: Re: [squid-users] Strange Squid SSL Interception Behavior
 
On 8/26/20 9:13 AM, Amos Jeffries wrote:
> On 26/08/20 11:03 pm, Mathew Brown wrote:
>> Thank you Alex + Amos :) You've really helped clarify things. I had a
>> final question regarding this setup. Does this configuration only look
>> at the client side part of the SNI request or also the server
>> certificate.

>> acl whitelist ssl::server_name .httpbin.org
>>
>> http_access deny CONNECT !SSL_ports
>> http_access allow localnet CONNECT
>>
>> ssl_bump peek step1
>> ssl_bump splice whitelist
>> ssl_bump terminate all


The above ssl_bump configuration ignores the TCP client information
(during step1) and looks at TLS client information (during the next step
-- step2). With this configuration, Squid will not see the server
certificate at all.


>> If it only looks at the client-side, how would I tell it to
>> look at the server response as well?

If you want Squid to consider the server certificate as well (during
step3), replace "step1" with "all". See ssl::server_name ACL for the
documentation of what "as well" really means in this context. Its
complicated.


> The process is all described at
> https://wiki.squid-cache.org/Features/SslPeekAndSplice

Yes, and also see the documentation for the ssl::server_name ACL. In
modern Squids, you can control what information that ACL is using.


BTW, I just realized that my earlier statements about reverse DNS
lookups were misleading: The ssl::server_name ACL does not do any DNS
lookups. When given an unresolved IP address, that ACL will usually
mismatch .httpbin.org (regardless of whether the reverse lookup would
have returned a matching domain name).


HTH,

Alex.

_______________________________________________
squid-users mailing list
[hidden email]
http://lists.squid-cache.org/listinfo/squid-users