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