On 29-10-12 13:42, Daniel Stenberg wrote:
> On Mon, 29 Oct 2012, Oscar Koeroo wrote:
>
>> 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.
>
> Sorry, but that's not now I read it and I disagree. I'm all for removing the
> difference between 1 and 2, which is what I'm suggesting and read your
> excellent write-up as backing up my position.
>
> I did not see a motivation to completely remove the support to disable the
> host name verification. Can you elaborate on why you think we should or need
> to do that?
>
> That feature is WIDELY used and thus we simply cannot do that without an
> SONAME bump and that is a major headache and road block.

My perspective was from how cUrl is currently using the SSL backends and how
each of the SSL backends themselves implement the post connection checks to
comply with RFC2818 for example. I concur that the least intrusive change is
desired.

Bottomline: Using a setting of '1' as the new '2' will break the
compatibility with GnuTLS as it currently works up to and including 7.28.0.

We can currently ignore axTLS, CyaSSL and PolarSSL from the discussion. I
wans't able to find the Windows and OSX implementations for cUrl in my
curl-7_28_0, this could be done later, but let's ignore these for now too.
We can also ignore QsoSSL as I have a pretty ok bet going on that their API
doesn't allow to comply with RFC2818 at all.

This means we're left with GnuTLS and OpenSSL which use similar semantics
for the 0, 1, 2 value and NSS at the other end.

Giving VERIFYHOST...
A setting of 0:
* NSS: Skip/ignore all the hostname verifications.
* GnuTLS: Skip/ignore all the hostname verifications. (same as 1)
* OpenSSL: Non-matching SubjectAltNames is an error. Mismatch with /CN is
tolerated with a warning. (same as 1)

A setting of 1:
* NSS: Perform RFC2818 compliance checks (same as 2)
* GnuTLS: Skip/ignore all the hostname verifications (same as 0)
**Problematic!**
* OpenSSL: Non-matching SubjectAltNames is an error. Mismatch with /CN is
tolerated with a warning. (same as 0)

A setting of 2:
* NSS: Perform RFC2818 compliance checks (same as 1)
* GnuTLS: Perform RFC2818 compliance checks
* OpenSSL: Perform RFC2818 compliance checks

Why I advocate for removal of the VERIFYHOST setting completely is a bit
less well founded as I thought it was earlier this morning. My main
motivation was to make it your connection secure or not. This is a simple
and clear setting to be switched on or off by the VERIFYPEER option. And
that in the OpenSSL cUrl interaction the VERIFYHOST setting doesn't really
adds or removes too much from the verification step. SubjectAltNames are
pretty much the norm in commercial and academic CAs since a somewhere
between 2000 ~ 2003, with an unfortunately long tail. With these extensions
the setting is mute.

I'd like to make a second argument for this settings' removal of a multi-SSL
backend nature which is to make clear that axTLS, CyaSSL, GnuTLS, PolarSSL
and NSS have code to verify RFC2818 compliance. This can be exposed to cUrl,
e.g. axTLS, CyaSSL and GnuTLS with the gnutls_x509_crt_check_hostname()
function, or it can be implemented deeper embedded in the SSL library
itself, e.g. PolarSSL and NSS.

Only OpenSSL forces cUrl to bring your own post connection checks and you
need to DIY RFC2818 compliance in to cUrl. Only in the DIY solution you can
split the three possible checks mentioned in RFC2818, of which the
interaction between cUrl and OpenSSL implements the common two
(SubjectAltNames and CN matching).

With this as a given I'd like to still vote for making this VERIFYHOST
option completely disappear or at least mute. With a value of 0 it
undermines the VERIFYPEER setting of 1 by still being able to perform a
Man-in-the-Middle and when cUrl accepts the future patches to make
interactions with RFC2818 compliant (and thus secure) there will be more SSL
implementation where you can't make the distinction between subjectaltnames
and CN matching or you don't even have an option to ignore only the hostname
matching part (PolarSSL).

I hope this helps.

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