On 25/05/11 05:45, Ming Fu wrote:
Hi Alex,
One question about sslbump implementation, was the client side cert
exchange done before squid start the ssl to the server? If so, it
might be too late when squid learns that the server cert is not good.
The client side cert was already sent out.
(wrong Alex methinks, the designer of ssl-bump is Alex on squid-dev
mailing list).
It is too late to alter the client certificate. By the time a server
connection is opened Squid may have already served replies out of cache
to the client.
There are security re-check features built into SSL, however these are
now considered far too dangerous to be used and no sane agent will
perform them.
If the client side cert was exchanged after the server side, I am
willing to experiment with the openssl to see if purposefully sign a
flawed cert is possible.
*All* the certificates sent by Squid ssl-bump are "flawed" if you
consider their basic forgery falseness and signing by a fake CA to be a
flaw.
The sslproxy_cert_error access control I assume you are referring to
will accept any fast ACL type. Not just the dst example ACL. You should
also be able to use ca_cert ACL to permit certain types of certificate
problem.
Meanwhile it is worth investigate why you are getting so many failures...
There are many sites suffering from certificate failure because the
clients have obsolete CA-certificate packages installed. Check that
Squid has a most up-to-date CA certs you can get.
Others suffer because they are signed by a CA which is not officially
recognized by the OpenSSL project (thus no "official" CA distributed).
These CA can be manually added to your OS acceptable CA and Squid will
suddenly work for all the sites they sign.
Amos
--
Please be using
Current Stable Squid 2.7.STABLE9 or 3.1.12
Beta testers wanted for 3.2.0.7 and 3.1.12.1
