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

From: Christos Tsantilas <>
Date: Thu, 22 Dec 2011 15:38:54 +0200

On 12/22/2011 11:01 AM, Sean Boran wrote:
> Thanks.
> I also found a page that explains several things about sslbump that I
> did not understand yet, e.g. how to ignore domain errors:
> Error messages:
> /usr/local/squid/share/errors/templates/error-details.txt is very
> interesting indeed, thanks.
> Its make me wonder a bit though.
> When visiting a site with an invalid cert one sees:
> -- snip--
> The following error was encountered while trying to retrieve the URL:
> Failed to establish a secure connection to
> The system returned: (71) Protocol error
> This proxy and the remote host failed to negotiate a mutually
> acceptable security settings for handling your request. It is possible
> that the remote host does not support secure connections, or the proxy
> is not satisfied with the host security credentials.
> -- snip--
> i.e. the specific cert problems are not transmitted to the end user
> (expired cert, self signed), nor the cert contents
> "/C=--/ST=SomeState/L=SomeCity/O=SomeOrganization/OU=SomeOrganizationalUnit/CN=localhost.localdomain/emailAddress=root_at_localhost.localdomain".
> Is this something that can be improved already, or does one have to
> wait for the this first:
> ?

I see. The ERR_SECURE_CONNECT_FAIL error page does not provide the SSL
error details. It return only a system error...
You may want to open a bug report for this problem.

However it is not so difficult to fix it with your own.
You can add the following two lines in your ERR_SECURE_CONNECT_FAIL
error templates:
<p id="sysmsg"> Error Name: <I>%x</I> </p>
<p id="sysmsg">Error details:<I> %D</I> </p>

The "%x" formating code replaced with the SSL error name and the "%D"
replaced with the error details.

The error details for an SSL error can be customized using the
"error-details.txt" templates.

> MimicSslServerCert: I'll followup separately on that, thanks.
> Regards,
> Sean
> On 21 December 2011 18:02, Christos Tsantilas <> wrote:
>> 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
>>> 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 and in the user's browsers it
>>> looks like 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:
>> 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 ^
>>> 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
>> 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
>>> ?
>>> 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 /
>>> So, then I deleted 0757348E.pem to force a new cert to be generated,
>>> and restarted squid.
>>> Connecting to 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 to initiateSSL() in
>>> and finally ssl_verify_cb in ssl/
>>> 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 Thu Dec 22 2011 - 13:39:07 MST

This archive was generated by hypermail 2.2.0 : Thu Dec 22 2011 - 12:00:03 MST