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
