[squid-users] Issues with TLS inspection- 3 Follow up question

Wed Jan 29 03:32:04 UTC 2020

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-request at lists.squid-cache.org>
wrote:

> Send squid-users mailing list submissions to
>         squid-users at 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-request at lists.squid-cache.org
>
> You can reach the person managing the list at
>         squid-users-owner at 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 <squid3 at treenet.co.nz>
> To: squid-users at lists.squid-cache.org
> Subject: Re: [squid-users] Issues with TLS inspection-2
> Message-ID: <c91678b8-fd3f-2535-8d14-8dbbdcae9324 at 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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>
>
> ------------------------------
>
> End of squid-users Digest, Vol 65, Issue 33
> *******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20200128/65af6da0/attachment.html>