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
