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: > 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 ? 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 <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 >
