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. Squid file: 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 Thanks for the help! Aashutosh K On Thu, Jan 23, 2020 at 4:01 AM <squid-users-requ...@lists.squid-cache.org> wrote: > Send squid-users mailing list submissions to > squid-users@lists.squid-cache.org > > 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-requ...@lists.squid-cache.org > > You can reach the person managing the list at > squid-users-ow...@lists.squid-cache.org > > 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 <squ...@treenet.co.nz> > To: squid-users@lists.squid-cache.org > Subject: Re: [squid-users] Issues with TLS inspection-2 > Message-ID: <c91678b8-fd3f-2535-8d14-8dbbdcae9...@treenet.co.nz> > 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@lists.squid-cache.org > http://lists.squid-cache.org/listinfo/squid-users > > > ------------------------------ > > End of squid-users Digest, Vol 65, Issue 33 > ******************************************* >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
