Fwd: Re: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users

[Richard Moore]

On 7 May 2012 06:25, Nikos Mavrogiannopoulos <nmav at gnutls.org> wrote:
> On 05/07/2012 02:31 AM, Daniel Kahn Gillmor wrote:
>
>> In particular, i wanted to take Ludwig's concern seriously here:
>>> Openssl in all it's
>>> ugliness at least provides SSL_CTX_set_default_verify_paths(). gnutls
>>> doesn't have an equivalent. It's utterly stupid to require each and
>>> every application to hard code the path to a certificate bundle.
>>> Defaulting to not doing any checks at all if the application programmer
>>> forgot to set the magic option isn't exactly clever either.
>> Is there a way that GnuTLS can help facilitate proper peer verification
>> by application (or library) developers who depend on the project?
>
>
> It is a nice point. Ludwig contacted us with a patch lately. I'm for
> such a patch, but there is no notion such as a system certificate
> bundle standardized (even for linux systems only), and openssl only
> points to a random CA list they ship. I don't consider it better
> practice than what we do.

All the linux distros configure openssl to use their own CA bundle,
and don't use the one openssl ships. The CA bundle they ship is
maintained like any other package.

>
> Moreover, a standard certificate bundle is not helpful at all, if it
> doesn't mention for which purpose those certificates are trusted. Are
> they trusted to certify stmp servers? incoming e-mail? web?

This limitation is true. Openssl doesn't really have support for that concept.

>
> The only system that provides it is windows, which is not our primary
> platform. The closest thing we have in gnome-based systems, is
> gnome-keyring which may not be widely available to depend on.
>
>> As a baseline, are there documentation improvements we could offer, or
>> best practice guidelines we should be encouraging?  More aggressively,
>> is there some way we could consider offering a simple best-practice
>> certification config in the priority string, or as default behavior if
>
>> no other verification mechanism is specified?
>
> The initial idea was that applications know which certificates to
> trust, or which CAs to trust. For example I might trust verisign for
> web browsing but only my local CA for smtp.
>
> I still believe in the above, but for several applications it seems
> it may not make sense. Currently I like the part of the patch of Ludwig
> that introduces a gnutls_certificate_set_x509_system_trust(), but it
> doesn't set any defaults (because there don't exist in all systems).
> For that I'd like more input from the library users here. Are there
> standard practices in Linux distributions and other POSIX systems that
> would allow to deduce that there is a common trusted certificate bundle?

In Qt, we search the following directories (see
https://qt.gitorious.org/qt/qtbase/blobs/master/src/network/ssl/qsslsocket.cpp#line2389):

<<  "/etc/ssl/certs/" // (K)ubuntu, OpenSUSE, Mandriva, MeeGo ...
<< "/usr/lib/ssl/certs/" // Gentoo, Mandrake
<< "/usr/share/ssl/" // Centos, Redhat, SuSE
<< "/usr/local/ssl/" // Normal OpenSSL Tarball
<< "/var/ssl/certs/" // AIX
<< "/usr/local/ssl/certs/" // Solaris
<< "/opt/openssl/certs/"; // HP-UX

In addition where possible we use the directory version of the bundle
rather than the combined file (the directories are hashed allowing for
much faster access).

>
> Are there ways to identify the trust purpose of those certificates?
> Is there any intention to standardize something like that, so we don't
> end up with our own trust?

All the certs are trusted for all purposes in this scheme (subject to
the keyusage flags they contain).

Regards

Rich.

>
> regards,
> Nikos
>
>
> _______________________________________________
> Help-gnutls mailing list
> Help-gnutls at gnu.org
> https://lists.gnu.org/mailman/listinfo/help-gnutls