On October 24th, my twitter feed suddenly got more activity than usual when suddenly there’s a mention of a newly(?) published paper:<\/p>\n\n\n\n
The most dangerous code in the world: validating SSL certificates in non-browser software<\/strong><\/a><\/p>\n\n\n\n Within the twelve page document they discuss flaws in various APIs and other certificate checking software, and for libcurl they say:<\/p>\n\n\n\n Internally, it uses OpenSSL to verify the chain of trust and verifies the hostname itself. This functionality is controlled by parameters CURLOPT_SSL_VERIFYPEER<\/a> (default value: true) and CURLOPT_SSL_VERIFYHOST<\/a> (default value: 2). This interface is almost perversely bad. The VERIFYPEER parameter is a boolean, while a similar-looking VERIFYHOST parameter is an integer.<\/p>\n<\/blockquote>\n\n\n\n (The fact that libcurl supports no less than nine(!) different SSL library backends seems to have been ignored but is irrelevant.)<\/p>\n\n\n\n The final part is their focus. It is an integer option but it looks like it could be similar to the VERIFYPEER<\/a> option which could be considered a boolean option – but note that there is no boolean options at all in libcurl, those are all “long” values. They go on to explain:<\/p>\n\n\n\n Well-intentioned developers not only routinely misunderstand these parameters, but often set CURLOPT_SSL_VERIFY HOST<\/a> to TRUE, thereby changing it to 1 and thus accidentally disabling hostname verification with disastrous consequences<\/p>\n<\/blockquote>\n\n\n\n They back up their claim with some snippets from PHP programs showing wrong use in chapter 7.<\/p>\n\n\n\n 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.<\/p>\n\n\n\n They also only post examples of the bad use made by PHP code. The PHP code uses the PHP\/CURL binding<\/a> 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.<\/p>\n\n\n\n We’re now discussing this topic on the libcurl mailing list<\/a>. If you have ideas or suggestions or just comments, feel free to join in!<\/p>\n\n\n\n Oh, and I feel that my recent blog post on the non-verifying users<\/a> seems related and relevant.<\/p>\n\n\n\n I will also call the majority of all these suddenly appearing complainers on this API to be mostly\u00a0hypocrites\u00a0since the API has been established and working like this for over a 10 (ten!) years and not a single person has objected to it before. Joining up on the “bandwagon” now and calling the API stupid or silly is… well, I’d call it “non-intelligent behavior”. In libcurl we take a stable and solid API and ABI very<\/em> seriously. We simply do not break API nor ABI unless forced brutally into a corner we can’t escape otherwise. Therefore\u00a0we have kept this API to keep existing applications functional.<\/p>\n\n\n\n Update: <\/strong>the discussion thread on the topic from the PHP-DEV list<\/a>. Thanks to Jan Ehrhardt.<\/p>\n\n\n\n Second update:<\/strong> we shipped libcurl 7.28.1 <\/a>on November 20 2012, and it no longer accepts the value 1 to VERIFYHOST, but will instead cause curl_easy_setopt() return an error and use the default value (which is 2). This will prevent applications to accidentally be insecure due to use of 1.<\/p>\n","protected":false},"excerpt":{"rendered":" On October 24th, my twitter feed suddenly got more activity than usual when suddenly there’s a mention of a newly(?) published paper: The most dangerous code in the world: validating SSL certificates in non-browser software Within the twelve page document they discuss flaws in various APIs and other certificate checking software, and for libcurl they … Continue reading libcurl claimed to be dangerous<\/span> \n
\n