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

[Daniel Kahn Gillmor]

Hi GnuTLS folks--

The attached message came through oss-security recently [0], and i just
wanted to bring it to the attention of the users and developers of GnuTLS.

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?

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?

Any thoughts?  Is there already a helpful and useful response that we
can offer to Ludwig's complaint?

All the best,

        --dkg

[0] http://www.openwall.com/lists/oss-security/2012/05/04/6
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: [oss-security] CVE Request: evolution-data-server lacks SSL checking in its libsoup users
>
>
>
>
> Date: 
>
> Fri, 04 May 2012 13:00:45 +0200
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120421 Thunderbird/12.0
>
>
>
>
> Marcus Meissner wrote:
> > I started looking at the libsoup users, first one is evolution-data-server,
> > 
> > None of the libsoup users there seem to handle SSL certificate trust 
> > correctly (or at all) in my eyes.
> > 
> > In version 2.28 these are.
> >       Groupwise protocol handling (server/groupwise/e-gw-connection.c)
> >       Exchange protocol handling (server/exchange/lib/e2k-context.c)
> >       Google (servers/google/libgdata-google/gdata-google-service.c)
> >       calendar/backends/http/e-cal-backend-http.c
> >       calendar/backends/caldav/e-cal-backend-caldav.c
> > 
> > I do not fully understand the correct solution to this yet though, whether we 
> > need
> > to pass in additional flags, or evaluate the "trusted" flag after the connect.
>
> One would have thought that such abstraction libraries were invented to
> make life for application programmers easier. 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.
> I think we should just patch libsoup to do the checks by default against
> the system certificates instead of starting to patch all it's users.
> Since we do not have a certificate bundle file in older distros we'd
> need to patch libsoup to use the certificate directory instead anyways.
>
> I wonder why everyone insists in using an unmanageable bundle file
> instead of the directory with individual files...
>
> cu
> Ludwig
>
> -- 
>  (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) 
>
> --- End Message ---

signature.asc
Description: OpenPGP digital signature