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

[Ludwig Nussel]

Nikos Mavrogiannopoulos 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.

openssl doesn't ship certificates anymore since quite some time. So
we're using the root certs from mozilla. The update-ca-certificates
script¹ converts the file into the formats needed by various libraries.
Fedora, Debian, Ubuntu do something similar.

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

Mozilla does store such trust bits. Openssl also supports a special pem
format that carries this information. Since only openssl supports that
format we couldn't use it in /etc/ssl/certs so far though. Since email
and code signing don't really matter for us in practice /etc/ssl/certs
only contains certificates trusted for server auth. 

> 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.

Well, anything gnome based would be too high level.

>> 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.

That's a rather specific feature for advanced users though. In general
people don't care at that detail level. It would be nice to have for
sure though. The feature needs to be handled transparently by the
library too IMO.

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

It would be nice if there was something common. In Fedora and openSUSE
we at least add a textual header to the pem files that has the alias and
trust information from NSS.
Wrt a completely different trust store concept there's this draft which
describes what gnome-keyring does I think:
http://people.collabora.com/~stefw/trust-assertions.html

[1] http://gitorious.org/opensuse/ca-certificates/trees/master

-- 
 (o_   Ludwig Nussel
 //\
 V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)