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: http://wiki.squid-cache.org/Features/SslBump 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: https://wiki.squid-cache.org/ Failed to establish a secure connection to 77.93.254.178 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@localhost.localdomain". Is this something that can be improved already, or does one have to wait for the this first: http://wiki.squid-cache.org/Features/BumpSslServerFirst ; ? MimicSslServerCert: I'll followup separately on that, thanks. Regards, Sean On 21 December 2011 18:02, Christos Tsantilas <christos@xxxxxxxxxxxx> 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 > > 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
