Re: [pyOpenSSL] Problem with pyOpenSSL 0.10 and OpenSSL 0.9.8m

[M.-A. L. <ma...@eg...>]

ex...@tw... wrote:
> On 08:55 pm, ma...@eg... wrote:
>>
>> Thanks for the hint. Here's the full background:
>>
>> http://www.madboa.com/geek/openssl/#verify-system
> 
> Awesome link, thanks for finding it.
>
>> Different OSes place the trusted certificate database files in
>> different places and non of them uses the OpenSSL default which
>> is /usr/local/ssl and a subdir certs/.
> 
> The version of OpenSSL distributed by Ubuntu and Debian and by Apple in
> OS X 10.6 don't use the default, but the build configuration is
> correctly specified so that OpenSSL can find the certificates in the
> non-default location.
> 
> In a perfect world, this is how it would be on all platforms. :)

And it probably is on most platforms... I was testing with our
embedded OpenSSL solution which uses the OpenSSL build defaults.

Since most OSes appear to use non-standard certificate database
locations, there's little hope of relying on the default verify
path compiled into OpenSSL in such a case.

>> The only way to work around this appears to be to call
>> ctx.load_verify_locations() to point the context to the
>> right set of trusted certificates.
>>
>> I believe that the test should apply such a setup for
>> the verisign.com certificate authority instead of
>> relying on a platform provided default setup, ie. use
>> its own certs/ subdir with the root CA certificates that
>> are used by verisign.com.
> 
> The test in question is for ctx.set_default_verify_paths.  It does seem
> very likely that calling ctx.load_verify_locations with a path known to
> contain the necessary CA certificate would make the test pass, but then
> it would be testing something else. :)

True. I missed that point :-)

> I'll definitely agree that this is not a very good unit test, for a
> number of reasons.

I guess using that API with our pyOpenSSL distribution is
not really all that useful. OTOH, explicit is better than
implicit and IMHO it's better to explicitly have the user
or application define which root CAs to trust or not.

We'll add a note to the web page.

>> In any case, the above test failure is a problem with the test
>> setup more than anything else.
> 
> I agree.  I think it might make sense to try to determine if the libssl
> being used was built in a way that could allow the necessary CA cert to
> be found, and skip the test if it was not.  Running "openssl version -d"
> and checking what's in that directory might be a good heuristic.

That won't work with our embedded version, since we don't ship the
openssl executable, only the libs.

Too bad, that there's not SSL_CTX_get_default_verify_paths().

>> Here's a version of the test which works on OpenSUSE:
>>
>> [snip]
> 
> Any chance you could agitate to have the OpenSUSE build fixed so that
> ctx.set_default_verify_paths can actually work? :)
> 
> If all the major platforms had a properly built version of OpenSSL, I
> think it'd be a lot easier for people to write well-behaved SSL
> applications.

OpenSUSE's OpenSSL libs do have the paths correclty defined.

It's just that those OS libs often tend to be rather outdated
and, in some cases, also have (had) serious bugs. That's the
reason why we've created the eGenix pyOpenSSL distribution -
it includes the OpenSSL libs embedded in the OpenSSL package
and does not rely on the system provided ones.

A side effect of this, is that the default OPENSSLDIR is
(currently) set to /usr/local/ssl for those libs, so it's
rather unlikely that the libs find the OS provided default
collection of trusted root CA certs.

Perhaps we should change the default to either /dev/null
to make this even more secure in the "explicit is better
than implicit" sense or add a function which tries to determine
the OS default location for the root CA certs in order
to help the developer in adding support for trusting these.

Our own use case, the mxODBC Connect product, doesn't need
all this, since you have to explicitly define the trusted
certificates anyway.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Source  (#1, Mar 16 2010)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/
________________________________________________________________________

::: Try our new mxODBC.Connect Python Database Interface for free ! ::::


   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
    D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
           Registered at Amtsgericht Duesseldorf: HRB 46611
               http://www.egenix.com/company/contact/