[gnutls-help] Advice for handling POODLE vulnerability

Nikos Mavrogiannopoulos nmav at gnutls.org
Fri Oct 17 06:17:17 CEST 2014

On Thu, 2014-10-16 at 18:09 -0500, Michael Catanzaro wrote:
> Hi,
> I'm looking for some advice on how to plug the POODLE vulnerability in
> WebKitGTK+. We use GnuTLS indirectly through libsoup, which uses glib,
> which uses glib-networking, which uses GnuTLS.  glib does not currently
> offer the ability to control the protocols or cipher suites in use.
> Traditionally, glib-networking has not changed any GnuTLS defaults, on
> the assumption that your defaults will always be better and more secure
> than anything the glib developers could come up with. But since it looks
> like SSLv3 will not be disabled until GnuTLS 3.4, and we need to
> immediately disable SSLv3, this no longer seems like a reasonable option
> for glib. In order to avoid breaking applications that require SSLv3,
> the current consideration is to add new API in glib (and possibly also
> in libsoup) for controlling protocols in use... but this seems like a
> poor way to handle a security issue, and would cause glib to default to
> insecure.

 I've posted a security advisory on [0]. The short answer is that you
don't need to do any changes, unless glib-networking does the
browser-like insecure TLS negotiation. If you are in that case SSL 3.0
will only be negotiated as fallback, if neither of the parties support
anything better.

If on the other hand glib-networking perform the insecure TLS
negotiation, it should be modified not to try SSL 3.0 as part of it.

In any case, I think that offering an API to control the SSL 3.0 usage
per application will cause more issues than it will solve. By the time
you introduce it applications would use it to avoid compatibility
issues, and SSL 3.0 will stay on indefinitely until someone notices. 

[0]. http://www.gnutls.org/security.html#GNUTLS-SA-2014-4


More information about the Gnutls-help mailing list