Once again the internet flooded over with reports and alerts about a vulnerability using a funny name: POODLE. If you have even the slightest interest in this sort of stuff you’ve already grown tired and bored about everything that’s been written about this so why on earth do I have to pile on and add to the pain?
This is my way of explaining how POODLE affects or doesn’t affect curl, libcurl and the huge amount of existing applications using libcurl.
Is my application using HTTPS with libcurl or curl vulnerable to POODLE?
No. POODLE really is a browser-attack.
Motivation
The POODLE attack is a combination of several separate pieces that when combined allow attackers to exploit it. The individual pieces are not enough stand-alone.
SSLv3 is getting a lot of heat now since POODLE must be able to downgrade a connection to SSLv3 from TLS to work. Downgrade in a fairly crude way – in libcurl, only libcurl built to use NSS as its TLS backend supports this way of downgrading the protocol level.
Then, if an attacker manages to downgrade to SSLv3 (both the client and server must thus allow this) and get to use the sensitive block cipher of that protocol, it must maintain a connection to the server and then retry many similar requests to the server in order to try to work out details of the request – to figure out secrets it shouldn’t be able to. This would typically be made using javascript in a browser and really only HTTPS allows this so no other SSL-using protocol can be exploited like this.
For the typical curl user or a libcurl user, there’s A) no javascript and B) the application already knows the request it is doing and normally doesn’t inject random stuff from 3rd party sources that could be allowed to steal secrets. There’s really no room for any outsider here to steal secrets or cookies or whatever.
How will curl change
There’s no immediate need to do anything as curl and libcurl are not vulnerable to POODLE.
Still, SSLv3 is long overdue and is not really a modern protocol (TLS 1.0, the successor, had its RFC published 1999) so in order to really avoid the risk that it will be possible exploit this protocol one way or another now or later using curl/libcurl, we will disable SSLv3 by default in the next curl release. For all TLS backends.
Why? Just to be extra super cautious and because this attack helped us remember that SSLv3 is old and should be let down to die.
If possible, explicitly requesting SSLv3 should still be possible so that users can still work with their legacy systems in dire need of upgrade but placed in corners of the world that every sensible human has since long forgotten or just ignored.
In-depth explanations of POODLE
I especially like the ones provided by PolarSSL and GnuTLS, possibly due to their clear “distance” from browsers.
Daniel I really take issue with this post. You’re giving an authoritative ‘No’ to something that could be a possibility depending on how an application developer uses libcurl. Can you really say for certain nobody is using libcurl that way? Is it impossible to use libcurl that way? I recognize and respect you have the most experience here but I don’t see you saying it’s impossible to use libcurl in that way and unless you do I’m going to push this. My interpretation is there could be such cases and given that I think we as contributors should step in and make the necessary changes. I just finished a review of most of the code that I’ve worked on or support that uses libcurl and I didn’t find anything that could be exploited via POODLE. And probably (but not definitely) most people are going to be in the same position. The PolarSSL perspective you link to says it better: “If an attacker cannot actively control sending requests and the data in them, you are not affected by the POODLE attack.”
I don’t think I say that there’s absolutely no risk to anyone. I use the word “typically” to allow there to be cases that contradict what I say here. And you need more than to just “affect” requests and data to make use of this attack: you need to be able to insert quite a lot of logic and keep the connection while running it.
I’m not aware of anyone using curl or libcurl in a way that would make them vulnerable to this. (Not that I am aware of even a big portion of all the users.)
We will still avoid the renegotiation that can be done today and we will disable SSLv3 by default. Isn’t that just about what we can do, even if you think (your use of) curl is vulnerable?
What you have planned for the next release seems like a good move to me. I think the discussion on the mailing list has been beneficial. I disagree with your assertions in the blog post that libcurl is not vulnerable.
Can you name an application that uses libcurl or curl for that matter, that is vulnerable to POODLE?
No. As I alluded to in my earlier correspondence I think it’s a potential vulnerability and I think it’s wrong to say libcurl isn’t vulnerable.
Hi Daniel,
Could it be possible to make libcurl use tls as a default value? One of the measures is to turn off sslv3 in the server side. However, once this is done, curl (thru libcurl) has problems accessing a server that is run with openssl1.0 when the curl command is executed from a box that only has openssl 0.9.
The solution here is of course to do an explicit –tslv1 or -1.
I didn’t had this problem explicityl with curl but with a commercial product called prince that is dynamically linked with libcurl and for which we don’t have the source code, just the binary.
My short-term solution was to patch libcurl to make sure the default value
just before the options are read:
data->set.ssl.version = CURL_SSLVERSION_TLSv1;
This solved our problems with that piece of software.
Here’s more info on this problem as reported elsewhere:
http://stackoverflow.com/questions/8619706/running-curl-with-openssl-0-9-8-against-openssl-1-0-0-server-causes-handshake-er
Hope this helps.
For proper libcurl help and questions, please use the curl-library mailing list. Neither this place nor stackoverflow are very suitable.