On 10/24, Daniel Stenberg wrote:
> Hi friends,
>
> The Most Dangerous Code in the World: Validating SSL Certificates in
> Non-Browser Software" is a report from 6 authors I noticed today:
>
> http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
>
> Among many things it has the following charming remark about
> libcurl's API: "This interface is almost perversely bad."
>
> From what I understand, the single reason behind that statement is
> that we have the CURLOPT_SSL_VERIFY HOST option which takes a
> three-value option and not just a boolean. The authors found several
> source codes that treated it as a boolean and set it to TRUE (== 1)
> and thus it doesn't check the certificate properly.
>
> So instead of posting a patch to us, instead of mailing us a
> suggestion, instead of posting a bug report they write this
> document.

The whole point against libcurl in that paper is that a bunch of PHP projects
(which I never heard of before) misuse the SSL_VERIFYHOST option.

Now, I'm not a PHP expert (or a PHP user at all), but I downloaded a couple of
the projects mentioned in the article and grepped for VERIFYHOST: in zencart
AFAICT all the plugins that use that option specify the value "2", and as for
oscommerce there's no trace of that option being set anywhere in the code (but
it does set VERIFYPEER to false, which is definetely not curl's fault).

It may just be that they have fixed those problems when contacted by the authors
of the paper (though I do not see any trace of this in their changelogs) but
personally I've already wasted too much time with this.

Cheers

-- 
perl -E '$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html