Re: [squid-users] ssl-bumping certificate validation (on OSX)

From: Alex Rousskov <rousskov_at_measurement-factory.com>
Date: Tue, 19 Mar 2013 12:41:53 -0600

On 03/19/2013 10:29 AM, Jeff Warren wrote:
> Hi,
>
> I've been trying, with mixed success, to package a version of squid for
> redistribution on OSX with ssl-bumping for the purpose of restricting access
> to certain URLs.
>
> On some test machines, everything works perfectly - SSL connections are
> decrypted, and reencrypted with a generated cert signed by my testCA. On
> others, an untrusted cert is returned, issued by 'Not trusted by "testCA" '.
> Previously I encountered a squid error of
> X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT_LOCALLY, is this the same behaviour
> except handled differently, as I am now using squid 3.3.3 with
> bump-server-first?

Yes, most likely. If Squid cannot validate the origin server
certificate, Squid will not (by default) sign the connection using a
Squid certificate that browsers will trust. Doing so would hide the
validation problem from the user.

> I understand that openssl is used as a library, and that the command line
> binary is irrelevant to squid for validation.

The last bit is not exactly true. The command-line OpenSSL tools are
relevant as long as they use the same OpenSSL library and configuration
as Squid.

> Thus to improve portability, I
> configured with the following flags:
>
> '--enable-ssl' '--enable-static' '--with-openssl=/usr/include/openssl'
> '--enable-strict-error-checking=no' '--enable-ssl_crtd'
>
> Am I correct in believing that this should be linking against openssl
> statically, and allowing the squid binary to be independent of the system
> version of openssl? Or, are libraries in some default location being used?
> Perhaps this isn't an openssl problem at all? Combing the logs on the
> problematic test machines has not yielded anything useful/relevant, though I
> can see that the original CA files are being downloaded from Verisign etc.
>
> The default command line openssl binary on the machine appears to validate
> certificates correctly, for example "openssl s_client -connect
> google.com:443" will result in "Verify return code: 0 (ok)"
>
> Any pointers appreciated!

The problem is most likely OpenSSL configuration, not version, although
default configuration problems can be version-specific. Your OpenSSL
configuration (used by the OpenSSL library used by Squid) probably lacks
Root CA certificates needed to validate the origin server certificate.

You can tell which OpenSSL libraries Squid is using by running "ldd" or
equivalent against the Squid binary (however even that test is subject
to environment variables that may be different in the Squid execution
environment!). If "ldd" tells you that the Squid executable is not a
dynamically linked one, then you built a static Squid binary.

If nothing helps, you may get more info by running Squid under strace or
similar and checking which OpenSSL files (including Root CA
certificates) OpenSSL opens. Compare that with the [Root CA certificate]
files that a successful s_client run opens.

For the record, there is more information/ideas at
http://bugs.squid-cache.org/show_bug.cgi?id=3796

HTH,

Alex.
Received on Tue Mar 19 2013 - 18:41:56 MDT

This archive was generated by hypermail 2.2.0 : Wed Mar 20 2013 - 12:00:06 MDT