[squid-users] Squid 3.5.27 - While access https website, always "Your connection is not secure"

[Amos Jeffries]

On 28/04/18 20:56, fourirakbar wrote:
> Maybe this is same with  this topic
> <http://squid-web-proxy-cache.1019090.n4.nabble.com/option-to-auto-recreate-the-ssl-db-td4682130.html> 
> . But now I use squid version 3.5.27
> 
> Here my squid version
> Squid Cache: Version 3.5.27
> Service Name: squid
> Ubuntu linux
> 
> This binary uses OpenSSL 1.0.2g  1 Mar 2016. For legal restrictions on
> distribution see https://www.openssl.org/source/license.html
> 
...
> 
> I also make follow this tutorial:  Dynamic SSL Cert
> <https://wiki.squid-cache.org/Features/DynamicSslCert>   from squid wiki.
> 
> *And my squid.conf*
...
> 
>     http_port 3128 ssl-bump \
>         cert=/etc/squid/ssl_cert/myCA.pem \
>         generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
>     http_port 3129 intercept
> 
>     https_port 3130 intercept ssl-bump \
>         cert=/etc/squid/ssl_cert/myCA.pem \
>         generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
> 
>     http_access allow  all

A bad idea. This disables ALL HTTP layer protections on traffic going
through this proxy.

> 
>     always_direct allow all 

No need to do this always_direct.

>     ssl_bump server-first all 

This deprecated.

>From <https://wiki.squid-cache.org/Features/SslPeekAndSplice> :
"
Old Squid-3.3 style bumping: Establish a secure connection with the
server first, then establish a secure connection with the client, using
a mimicked server certificate.

Does not support peeking, which causes various problems.

When used for intercepted traffic SNI is not available and the server
raw-IP will be used in certificates.
"

Also, the below DONT_VERIFY_PEER prevents Squid from checking that any
of those server details are in any way valid.

> 
>     sslproxy_flags DONT_VERIFY_PEER 

This disables all TLS/SSL security.

In short, do not do any of the above liens up to and including
"http_access allow all". 'insecure' is the least of your worries with
this as it currently is.

> 
>     # Just try to open instagram.com, but it also can't work. Same problem

Please explain "can't work". The below config *does not* have any Squid
involvement with instagram traffic - it is spliced. Which means it acts
exactly as if the proxy were not even there, the TLS is ONLY between the
client and server.

Also, if you leave the server-first stuff above this it takes priority
and none of the below will actually happen.

>     # acl whitelist ssl::server_name .instagram.com
>     # acl step1 at_step SslBump1
>     # ssl_bump peek step1
>     # ssl_bump splice whitelist
>     # ssl_bump bump all
> 
>     http_access deny !Safe_ports
>     http_access deny CONNECT !SSL_ports
> 

You do not have any rules permitting access to HTTP(S) traffic here.
Please at least limit the traffic through the proxy to your LAN ranges,
if not something better.

...
> 
>     #sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s
> /usr/local/squid/var/lib/ssl_db -M 4MB
>     #sslcrtd_children 5
> 
>     shutdown_lifetime 8 second 
> 
>     visible_hostname X450LD
> 
> 
> Now I try to open https://about.gitlab.com
> 
> *There is an error on cache log:*
>    ssl_crtd helper database '/var/lib/ssl_db' failed: Failed to open file
> /var/lib/ssl_db/index.txt
> 
> In browser (I use firefox), it show an error "your connection is not
> secure". I try add exception and view detail about certificate. And it show
> like the picture below
> <http://squid-web-proxy-cache.1019090.n4.nabble.com/file/t377437/gitlab5.png> 
> 
> And I compare with other client that the traffic not through my squid proxy
> <http://squid-web-proxy-cache.1019090.n4.nabble.com/file/t377437/gitlab4.png> 
> 
> Its different. How can solved this?

The Browser needs to trust the CA "Internet Widgets Pty Ltd". One
assumes that is the name of the issuer CA you created and put in
/etc/squid/ssl_cert/myCA.pem.

This is why all our tutorials at some point mention** the requirement to
add your custom CA to the client machine/software. SSL-Bump decryption
(bump, client-first and server-first actions) *will not* work without
that having been done. If you do not do that part the result is exactly
what you see happening.


** if any don't that is an oversight, please let us know.

Amos