On Mon, 29 Oct 2012, Oscar Koeroo wrote:

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

0 is per the documentation a skipped verification of the host name. The 'same
as 1' simply means that it logs a bad match and I don't think it matters much
as logging is basically only friendly if it isn't too slow/expensive in terms
of CPU or other resources.

Therefore I think all the above comply, and possibly that some checks in the
OpenSSL backend could be loosened for 0. That's a separate issue though.

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

The fact that the option 1 isn't working the same for all backends is just
another reason to move away from it, IMHO. I don't think that fact makes this
problematic.

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

... and that is how 2 is documented to work and should continue to do so.

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

One reason there are two options is that when you run a test server on your
development machine you can possibly still verify the cert's signature but
you'll not be able to verify the hostname so disabling the host name check
separately could be useful in some testing or development environments.

Of course, one can debate the value of this option since I believe almost
every single user in the world of this option also switched off the VERIFYPEER
option at the same time.

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

But the options 0, 1 and 2 are not about splitting the check in those
components as I think of them. The original functionality of course was made
back in the day when OpenSSL was the only supported backend so it can be
traced to those roots but in my mind the options have the following basic
meanings:

Option 0 is about not caring about doing the check at all.

Option 1 is about doing the test but only logging the result and not return a
failure even though the match failed. The documentation says the cert must
have a CN field, but as you already have pointed out that's not how it works
in reality with most backends. I don't think that detail makes much difference
here.

Option 2 is the default and is about doing the check properly and returning a
failure if the name check fails.

> With this as a given I'd like to still vote for making this VERIFYHOST
> option completely disappear or at least mute.

I think this is a very valid discussion but I don't think this is the time to
do it.

I want this VERIFYHOST adjustment to have as little effect as possible on the
world's "properly written" libcurl using programs. I claim that programs that
switch off hostname checking with VERIFYHOST set to 0 are validly written
programs and I don't think we have a well founded argument to remove that
functionality without an SONAME bump.

Having it set to 1 is also valid of course since it is documented, but since
the backend support for 1 is inconsistent and the option seems to be used by
mistake at least in several PHP programs are reasons enough to reconsider its
right to exist.

The bigger question to me is wether we as providers of a *rock solid* ABI can
change the behavior for this opion in this way without doing an SONAME bump.
Or perhaps put another way: if this can't be done within the same SONAME,
which way can we take?

I will not bump the SONAME for this. I will climb really steep hills first
before I even start thinking of doing an SONAME bump.

> With a value of 0 it undermines the VERIFYPEER setting of 1 by still being
> able to perform a Man-in-the-Middle

Of course. Both VERIFYHOST and VERIFYPEER are about switching off security.
There's no doubt about that and that's no secret and should not be so to
anyone who reads the documentation for them.

But I have deemed it not to be my crusade to forbid or prevent users from
shooting themselves in their feet if they really insist. That doesn't seem to
be the curl spirit. Instead we hand our users the gun with the instructions
clearly documented that explains what happens if you point it to somewhere
sensitive and press the trigger. Of course we should still help our users to
do the right thing, and one way is for example to make sure that we use
sensible and secure defaults.

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

0 ignores the check

2 uses the check

No problem here!

Of course there may still be bugs in one or more SSL backends, but they are
still just... bugs and should be fixed independently.

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