cURL / Mailing Lists / curl-library / Single Mail


Re: CVE-2013-4545 and GnuTLS backend

From: Daniel Stenberg <>
Date: Sat, 30 Nov 2013 10:41:33 +0100 (CET)

On Sat, 30 Nov 2013, Oscar Koeroo wrote:

> 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."

First, I'd rather discuss what _we_ said about the problem rather than what
someone else translated into the CVE text. We didn't author the above
paragraph. We got the CVE number based on our text.

> 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.

You're throwing the same argument against this that others already have.

Primarly, this isn't true. If you use other means you can make the peet
verification yourself and that's what at least one application has done. I'm
not in a position to question if they truly made it very secure or not, the
fact remains that they do this. I am to dismiss that and say they can't have
name checks if they disable the "peer check" ?

And secondly, if you disable peer verification in libcurl, the name check
should still work. That's what the documentation says. Failing that is thus a
bug, and if you're then assuming that the check works and you do the first
part on your own... you have a problem.

> 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?

We're not necessarily talking self-signed, but checked, assumed or vetted
outside the normal libcurl flow yes. And then the name check should work as

> 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.

The NSS exception is documented, and so should the others be if they exist.

CVE-2013-4545 is a real if even rather miniscule risk to a small set of
programs. In fact I only know of one that is affected.

List admin:
Received on 2013-11-30