On 29-10-12 16:03, Daniel Stenberg wrote:
> 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.

The CPU intensive bit is flipped with the VERIFYPEER variable. Walking
around in memory through some ASN.1 constructs (OpenSSL) or taking
pre-parsed X.509 (a bunch of others) and then performing a set of string
compares is not that intensive as chain validation ;-)

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

Yes, I had the same rational behind these switch. In some backend switching
off VERIFYPEER simply implies ignoring the entire VERIFYHOST option.

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

Ok, let's try to avoid this. It's going to be quite a hike before we reach a
steep hill like Kebnekaise and I don't have the shoes for it...

Is it an option to always provide debugging output in debugging mode
(=VERIFYHOST = 0)? In some SSL backends this is exclusive to enabling option
2 and completely skipped when setting the 0 option. This will assist
dry-run/deployment testing/debug cases and IMHO also assist the move for
developers from 1 to a 0 where applicable.

Perhaps an easier thing is to split the VERIFYHOST setting from what the SSL
backend is expected to do. A setting of 0 clearly means tolerate mismatches
and/or 'debug', and the option of 2 is 'secure all the things'. It would be
a lot more helpful to only use two distinct settings in the SSL backend;
being 'debug' xor 'secure' without the mediocre option in the middle. This
will harmonize the behaviour of the backends, I can very much appreciate
this as a developer using libcurl.

With respect to the option 1 provided from the application; I can only see
four migration paths of choices in this:
a. treat a 1 as a 0, forced debug mode
b. treat a 1 as a 2, forced secure connection
c. arbitrate per SSL backend what best to do. For GnuTLS that means
   treat a 1 as a 2, but for other SSL backends, treat it as a 0.
d. treat a 1 as an error and force people to change their code.

Option a will let all the application using cUrl work, but MitM is going to
be on the rise. Given the paper option b is best and frankly I favor this.
Option c would be mimicking the current state best for backwards
compatibility, with a motivation for a perfect fit and change slowly per SSL
backend, but will add a boatload of confusion. Option d will break
applications, IMHO a no-go.

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