On 29-10-12 10:33, Daniel Stenberg wrote:
> On Mon, 29 Oct 2012, Peter Sylvester wrote:
>
>> Do I understand correctly: verify_host will have two values, i.e equiv to
>> a bool?
>
> (For all new and old readers, this is a discussion around my *proposed*
> changes as shown in the patch I posted the other day.)
>
> Yes, that is what I'm suggesting. 0 or 2. With 1 then getting treated as
> illegal which internally will cause it to equal 2. (Within libcurl the value
> becomes a plain simple boolean though.)
>
> The discussion about named constants is all good and I wholeheartedly agree
> with it and I am a big proponent of using names instead of magic numbers.
>
> However, introducing these names *now* will also make users of the new
> defines not being able to copy their source code back to building with older
> libcurl headers so the documentation needs to be very clear on this part.
>
> Possibly we could use these names:
>
> CURLVERIFYHOST_IGNORE (0)
>
> CURLVERIFYHOST_PROPERLY (2 - default)
>
> All other values are considered illegal and will be ignored.
>

Hi,

I've send an email yesterday evening about all the various backends and how
they implement, for example, RFC2818 compliance and in particular I checked
how this VERIFYHOST setting is actually used and I'd like to propose the
removal or muting (for backwards compatibility) of the use of the VERIFYHOST
setting completely. By doing this cUrl's interoperation between (at least) 6
out of the 8/9 SSL stacks will be able to be equalized on this respect. Here
is a summary of my email per SSL stack interaction in cUrl and my conclusion
at the bottom:

Here's a summary:

Untested: Windows and OSX/iPhone SSL implementations.

axTLS, CyaSSL, PolarSSL:
These do not use the VERIFYHOST setting at all. There is no way to override
the settings. Curl's use of acTLS, CyaSSL and PolarSSL needs patching,
because they have security risks. See my email of 28-10-2012, 22:25pmCET for
details.

NSS:
VERIFYHOST = 1 equals VERIFYHOST = 2.

When NSS can't find SubjectAltNames it sets the
SEC_ERROR_EXTENSION_NOT_FOUND error. NSS will continue to the CN fields.

If the CN doesn't match an IP-address, or doesn't match the hostname it will
cast an SSL_ERROR_BAD_CERT_DOMAIN. BUT also when the SubjectAltNames don't
match the hostname it will set the SSL_ERROR_BAD_CERT_DOMAIN. This is
similar to GnuTLS.

GnuTLS:
VERIFYHOST = 0 equals VERIFYHOST = 1

GnuTLS internally checks the SubjectAltNames, and when absent the CN fields
according to RFC2818. A failure for both the SubjectAltNames and/or the CN
fields is treated as equal to gnutls_x509_crt_check_hostname(). This is
similar to NSS.

QsoSSL:
VERIFYHOST = 1 equals VERIFYHOST = 2

Seems to be incapable of being RFC2818 from the SSL library itself. Setting
an "accept all the certificates" when VERIFYHOST is 0 doesn't look good.

OpenSSL:
VERIFYHOST = 0 equals VERIFYHOST = 1

The VERIFYHOST value only kicks in when the SubjectAltNames don't exist. The
code will not even use the VERIFYHOST value if you have a normal certificate
with SubjectAltNames in them (see: RFC5280 and RFC2818 for motivation).

Besides the differences in the VERIFYHOST value used in cUrl per SSL
implementation the VERIFYHOST seems to only be of interest when a normal
RFC2818 HTTP over TLS check has failed and cUrl has to resort to the legacy
checking method of matching a CN.

I would like to propose to complete abandon the VERIFYHOST option to favor
strict security to avoid undesired mistakes. After all, why would VERIFYPEER
have an matching effect on the SubjectAltNames in all SSL implementations
(failure here, equals *bust* you are out), but the VERIFYHOST only reflects
the CN field checking.

My proposal will *equalize* the interactions between GnuTLS, OpenSSL and NSS
on this post connection verification step implementing RFC2818 in cUrl. When
implemented properly it will also equalize with PolarSSL, CyaSSL and axTLS

Yes, this basically means: ignore any usage of VERIFYHOST and remove all the
reference besides just blindly accepting a setting and stating that it's
CURL_OK when you pass it for backwards compatibility.

        Oscar
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2012-10-29