On 29-11-13 22:44, Daniel Stenberg wrote:
> On Fri, 29 Nov 2013, Marc Deslauriers wrote:
>
>> I was just looking at the patch for CVE-2013-4545
>> (http://curl.haxx.se/docs/adv_20131115.html), and I believe the GnuTLS
>> backend has the same problem.

The CVE ticket states:

"cURL and libcurl 7.18.0 through 7.32.0, when built with OpenSSL,
disables the certificate CN and SAN name field verification
(CURLOPT_SSL_VERIFYHOST) when the digital signature verification
(CURLOPT_SSL_VERIFYPEER) is disabled, which allows man-in-the-middle
attackers to spoof SSL servers via an arbitrary valid certificate."

I fail to see the root of the problem because the peer verification
needs to be disabled, thus all bets are off with respect to the checks
related to the content of the certificate. No part in curl or the
SSL-backend now has a trust relationship with the peer by means of this
explicit setting. Only if the content happens to be non-tampered it is
of interest that RFC2818-checks are performed and fail or succeed.

Sure, I could have a self-signed certificate up on a site and I wish to
check that this has the right SAN or Common Name on it, but what risk
did we mitigate by changing the flow?

As a note on other backends: all the backend feature a similar flow.
Some backends, if I'm not mistaken PolarSSL and NSS, won't let you
change the behaviour because the RFC2818 stuff can only be done as a
part of the peer verification checks.

        Oscar

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