On 11/27/23 11:11, Amos Jeffries wrote:
First off, thanks for answering.
For further assistance please also show your http_access and ACL config
lines. They will be needed for a better analysis of what is going on.
I'll start from here.
It's quite long, but a reduced example is:
acl localnet src 10.1.2.0/24
acl bumphosts src 10.1.2.18
acl SSL_ports port 443
acl SSL_ports port 563 801 3001 8443 19996 19997
acl Safe_ports port 80 # http
acl Safe_ports port 800
acl ftptraffic myportname ftpport
acl fetched_certificate transaction_initiator certificate-fetching
acl splicedom ssl::server_name_regex -i "/usr/local/etc/squid/nobumpsites"
acl step1 at_step SslBump1
ssl_bump splice !bumphosts
ssl_bump splice splicedom
ssl_bump peek step1
ssl_bump bump all
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
adaptation_access service_req deny ftptraffic
adaptation_access service_resp deny ftptraffic
http_access allow localnet
http_access allow localhost
For the sake of an example, let's say I connect from 10.1.2.18 to
www.google.com.
FYI, Intercepted traffic first gets interpreted as a CONNECT tunnel to
the TCP dst-IP:port and processed by http_access to see if the client is
allowed to make that type of connection.
Fine.
Traffic is in fact allowed.
To guess based on the info provided above I suspect that the
fake-CONNECT raw-IP does not match your "bumphosts" ACL test. Causing
that "ssl_bump splice !bumphosts" to occur.
Not sure I understand what you mean: is raw-IP the source (in my case
10.1.2.18) or the destination IP (142.251.209.36)?
"bumphosts" ACLs are local clients (those that SSLBump should be applied
to): 10.1.2.18 is in this list (in fact it gets SSLBump if explicitly
using the proxy).
This is what I see in the logs for an intercepted connection (after it's
closed):
1701100166.601 2203 10.1.2.18 TCP_TUNNEL/500 6622 CONNECT 142.251.209.36:443 - ORIGINAL_DST/142.251.209.36 -
This is what I see using a proxy-aware application:
1701100243.374 172 10.1.2.18 TCP_MISS/200 49333 GET https://www.google.com/? - HIER_DIRECT/142.251.209.36 text/html
That behaviour is why we typically recommend doing "peek" first, then
the splice checks can be based on whatever TLS SNI value is found.
I don't think it should matter: neither www.google.com nor
142.251.209.36 are in any ACL.
Or did I understand wrong?
Is this needed for intercepted SSLBump?
I think it worked in the past: has anything changed in this regard
with Squid 6?
Changed since what version? Over time a lot of small changes can add up
to large differences.
I first noticed this on 6.4.
Unfortunately I don't remember which version I was using at the time I
set this up, maybe 5.x, maybe even 4.x.
bye & Thanks
av.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
https://lists.squid-cache.org/listinfo/squid-users
