cURL / Mailing Lists / curl-library / Single Mail


SSLv3 fallback attack POODLE

From: Ray Satiro <>
Date: Wed, 15 Oct 2014 02:58:39 -0400

I read today of a new method to decrypt SSL called POODLE. If you
haven't read of it you should. It works by using SSL fallback behavior
to get SSLv3 which can now be decrypted [1][2].

I'm looking into different libcurl SSL backends and this attack.
Immediately one can use CURLOPT_SSLVERSION with CURL_SSLVERSION_TLSv1 to
force TLS.

The zeitgeist on SSLv3 now seems to be disable by default (personally I
agree), and I think we should discuss whether or not it should be
disabled by default in libcurl. I have started working on it [3], and
have disabled SSLv3 by default for darwinssl, schannel, cyassl, nss,
openssl. axTLS is not affected since it supports only TLS, and gnutls is
not affected since it already defaults to TLS 1.x.

If someone can pick up from here and:

Review my changes.

Testing; I don't have most of these backends set up.

Anything I'm missing like changes needed for other backends?

Change docs. I updated CURL_SSLVERSION_DEFAULT to add that starting in
7.39.0 (or an early patch instead?) SSLv3 is no longer part of the
default. Maybe other docs need to be changed as well?

I'm unsure about SSLv23_client_method calls in cyassl.c and openssl.c.
In cyassl I have CURL_SSLVERSION_DEFAULT fallthrough to
CURL_SSLVERSION_TLSv1, but there is a note "CyaSSL cannot be configured
to use TLS 1.0-1.2, TLS 1.0 is used exclusively". Is that information
current? I'm reading their manual and it looks very similar to OpenSSL.
Can't it just be set with SSLv23_client_method and then have SSLv3
removed to get a default of TLS 1.0 - 1.2 like in openssl.c? In
openssl.c I left it as SSLv23_client_method() since it is "handled later
with the context options".


List admin:
Received on 2014-10-15