Re: [squid-users] stopping sslbump to domains with invalid or unsigned certs

From: Christos Tsantilas <christos_at_chtsanti.net>
Date: Wed, 21 Dec 2011 19:02:20 +0200

On 12/20/2011 04:34 PM, Sean Boran wrote:
> Hi,
>
> sslbump allows me to interrupts ssl connections and run an AV check on them.
> It generates a certs for the target domain (via sslcrtd), so that the
> users browser sees a server cert signed by the proxy.
>
> If the target domain has a certificate that is expired, or it not
> signed by a recognised CA, its important that the lack of trust is
> communicated to the end user.
>
> Example, on connecting direct (not via a proxy) to
> https://wiki.squid-cache.org the certificated presented is expired 2
> years ago and not signed by known CA .
> Noext on connecting via a sslbump proxy (v3.2.0.14), the proxy creates
> a valid cert for wiki.squid-cache.org and in the user's browsers it
> looks like wiki.squid-cache.org has a valid cert signed by the proxy.
>
> So my question is:
> What ssl_bump settings would allow the proxy to handle such
> destinations with expired or non trusted sites by, for example:
> a) Not bumping the connection but piping it through to the user
> unchanged, so the user browser notices the invalid certs?

It is not possible yet. This feature described here:
 http://wiki.squid-cache.org/Features/MimicSslServerCert
But is not available at this time in squid. If you are interested for
this feature please contact Alex Rousskov and Measurement Factory.

> b) Refuses the connection with a message to the user, if the
> destination is not on an allowed ACL of exceptions.

Yes it is possible.

>
> Looking at squid.conf, there is sslproxy_flags, sslproxy_cert_error
> # TAG: sslproxy_flags
> # DONT_VERIFY_PEER Accept certificates that fail verification.
> # NO_DEFAULT_CA Don't use the default CA list built in
> to OpenSSL.
> # TAG: sslproxy_cert_error
> # Use this ACL to bypass server certificate validation errors.
>
> So, the following config would then implement scenario b) above?
>
> # Verify destinations: yes, but allow exceptions
> sslproxy_flags DONT_VERIFY_PEER
> #sslproxy_flags none
> # ignore Certs with certain cites
> acl TrustedName url_regex ^https://badcerts.example.com/
> sslproxy_cert_error allow TrustedName
> sslproxy_cert_error deny all

First comment out the sslproxy_flags configuration parameter. Then you
can use ssl_error acls to define which ssl errors allowed. An example
configuration which allows only the self signed certificates is the
following:

# comment out the sslproxy_flags
#sslproxy_flags DONT_VERIFY_PEER
acl SSLERR ssl_error X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT
X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN
sslproxy_cert_error allow SSLERR
sslproxy_cert_error deny all

A good source of the available errors in squid is your:
  "/your/squid/install/path//share/errors/templates/error-details.txt"

Unfortunately is not well documented in squid.conf...

Regards,
   Christos

>
> ==> But then, why does it not throw an error when connecting to
> https://wiki.squid-cache.org ?
>
> Next I though it might be an idea to delete any cached certs and try again.
> Looking in /var/lib/squid_ssl_db/index.txt, there is an extra for the
> destination:
> V 121107103058Z 0757348E unknown /CN=www.squid-cache.org
> So, then I deleted 0757348E.pem to force a new cert to be generated,
> and restarted squid.
>
> Connecting to https://wiki.squid-cache.org/ resulted in a new cert
> being silently generated, stored in 075734AD.pem and the https
> connection signed.
>
> What am I going wrong?
>
> Finally had a look at the sources:
> sslproxy_flags led to Config.ssl_client.flags in cf_parser.cci which
> led to ssl_client.sslContext in cache_cf.cc to initiateSSL() in
> forward.cc and finally ssl_verify_cb in ssl/support.cc.
>
> There one finds nice debugs prefixed with "83", so, enabled high
> debugging for 83:
> debug_options ALL,1 83,20 23,2 26,10 33,4 84,3
> Restarted squid, and watched with
> tail -f cache.log|egrep -i "SSL|certificate"
> but dont see certificate errors.
>
> Any suggestions?
>
>
> Thanks,
> Sean
Received on Wed Dec 21 2011 - 17:02:34 MST

This archive was generated by hypermail 2.2.0 : Wed Dec 21 2011 - 12:00:03 MST