libcurl claimed to be dangerous
On October 24th, my twitter feed suddenly got more activity than usual when suddenly there’s a mention of a newly(?) published paper:
Within the twelve page document they discuss flaws in various APIs and other certificate checking software, and for libcurl they say:
Internally, it uses OpenSSL to verify the chain of trust and verifies the hostname itself. This functionality is controlled by parameters CURLOPT_SSL_VERIFYPEER (default value: true) and CURLOPT_SSL_VERIFYHOST (default value: 2). This interface is almost perversely bad. The VERIFYPEER parameter is a boolean, while a similar-looking VERIFYHOST parameter is an integer.
(The fact that libcurl supports no less than nine(!) different SSL library backends seems to have been ignored but is irrelevant.)
The final part is their focus. It is an integer option but it looks like it could be similar to the VERIFYPEER option which could be considered a boolean option. They go on to explain:
Well-intentioned developers not only routinely misunderstand these parameters, but often set CURLOPT_SSL_VERIFY HOST to TRUE, thereby changing it to 1 and thus accidentally isabling hostname verification with disastrous consequences
They back up their claim with some snippets from PHP programs showing wrong use in chapter 7.
What did the authors do to try to fix the problem before posting rude comments in a report? Nothing. At. All. They could’ve emailed, tweeted or posted a bug report or patch but none of that happened.
They also only post examples of the bad use made by PHP code. The PHP code uses the PHP/CURL binding and a change could easily be done in the PHP binding. I don’t know PHP internals, but perhaps the option could be made to not accept a boolean value instead of a numerical there.
We’re now discussing this topic on the libcurl mailing list. If you have ideas or suggestions or just comments, feel free to join in!
Oh, and I feel that my recent blog post on the non-verifying users seems related and relevant.