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

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Help-gnutls mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/help-gnutls

Reply via email to