As suggested, I removed the settings for explicit proxy and have NAT move the HTTP/HTTPs request to squid intercept ports, and all the web traffic is now going through the proxy server (I see certs and connection requests in the cache log file).
I have a follow-up question. Any idea how do we accurately test to make sure if SSL bump is happening for a connection?
I have doubts as I was expecting, "Your connection is not Private" error when no CA cert on my browser. CA cert or no CA cert in my cert-manager does not affect the connection. Also, I read in some articles that dropbox and apple app store will not work if SSL Bump is active, but it works for me without any issues.
I was able to verify that websites in the ssl::server_name acl whitelist do not use squid generated certs for connection, as expected.
I have a follow-up question. Any idea how do we accurately test to make sure if SSL bump is happening for a connection?
I have doubts as I was expecting, "Your connection is not Private" error when no CA cert on my browser. CA cert or no CA cert in my cert-manager does not affect the connection. Also, I read in some articles that dropbox and apple app store will not work if SSL Bump is active, but it works for me without any issues.
I was able to verify that websites in the ssl::server_name acl whitelist do not use squid generated certs for connection, as expected.
Squid file:
Thanks for the help!acl localnet src 172.22.22.0/24
acl localnet src 172.16.10.0/24
acl localnet src 172.18.10.0/24
acl localnet src 10.0.0.0/8
http_access allow localnet
http_access allow localhost
acl CONNECT method CONNECT
http_access deny all
http_port 3129 intercept
https_port 3130 intercept ssl-bump cert=/etc/squid/ssl_certs/myCA1.pem generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/ssl_db -M 4MB
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
acl nobumpSites ssl::server_name "/etc/squid/whitelist.txt"
ssl_bump peek step1 all
ssl_bump splice nobumpSites
ssl_bump stare step2
ssl_bump bump step3
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
debug_options ALL,1 84,9 11,9 33,3 20,3 83,3 85,4 85,9
dns_v4_first on
shutdown_lifetime 5
Aashutosh K
On Thu, Jan 23, 2020 at 4:01 AM <squid-users-request@xxxxxxxxxxxxxxxxxxxxx> wrote:
Send squid-users mailing list submissions to
squid-users@xxxxxxxxxxxxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.squid-cache.org/listinfo/squid-users
or, via email, send a message with subject or body 'help' to
squid-users-request@xxxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
squid-users-owner@xxxxxxxxxxxxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of squid-users digest..."
Today's Topics:
1. Re: Issues with TLS inspection-2 (Amos Jeffries)
----------------------------------------------------------------------
Message: 1
Date: Fri, 24 Jan 2020 00:04:50 +1300
From: Amos Jeffries <squid3@xxxxxxxxxxxxx>
To: squid-users@xxxxxxxxxxxxxxxxxxxxx
Subject: Re: Issues with TLS inspection-2
Message-ID: <c91678b8-fd3f-2535-8d14-8dbbdcae9324@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8
On 23/01/20 3:11 pm, aashutosh kalyankar wrote:
> From: Amos Jeffrie>
> Secondly, make sure that your tests are accurately emulating how clients
> would "use" the proxy. That means making connections from a test machine
> directly to the Internet and seeing if the routing and NAT delivers the
> traffic to Squid properly.
>
>
> I am using a chromebook to test. In the configuration section of the
> wireless network there is an option to add proxy hostname and proxy port
> based on protocols.
> Http proxy : proxy-tls 80
> HTTPS proxy: proxy-tls 443
>
That is part of your problem. Those are settings for explicit proxy.
With intercept the clients knows nothing about any proxy. They are just
connecting to a web server directly (but *NAT* sends it to Squid instead).
>
> - Use cache.log to view the traffic coming into the proxy. It will be
> request messages with a prefix line indicating "Client HTTP request".
> Make sure that prefix line says the remote Internet IP address and port
> 80/443 you were testing with.
> - If you want confirm that access.log has a transaction entry for the
> URL you tested with ORIGINAL_DST and the server IP.
>
> Sample cache.log for a test I did for neverssl.com <http://neverssl.com>
>
> 2020/01/22 17:08:30.236 kid1| 11,2| client_side.cc(2346)
> parseHttpRequest: HTTP Client local=172.22.22.148:80
> <http://172.22.22.148:80> remote=172.22.22.151:34728
> <http://172.22.22.151:34728> FD 12 flags=33
> 2020/01/22 17:08:30.236 kid1| 11,2| client_side.cc(2347)
> parseHttpRequest: HTTP Client REQUEST:
> ---------
> GET http://neverssl.com/ HTTP/1.1
> Host: neverssl.com <http://neverssl.com>
> Proxy-Connection: keep-alive
...
>
> > http_access deny !Safe_ports
> > http_access deny CONNECT !SSL_ports
>
> ... this is where all your custom http_access rules are supposed to be.
> The Safe_ports and SSL_Ports lines above are DoS and hijack protections.
>
>
> IIUC, These are not required to be here so I commented out those lines.
>
Sorry if I was not clear. They should be the first http_access lines in
your config. Local policy rules follow them. Then the final "deny all"
rule to block anything not allowed by your policy.
Amos
------------------------------
Subject: Digest Footer
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
------------------------------
End of squid-users Digest, Vol 65, Issue 33
*******************************************
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
