On 04-11-12 11:19, Marc Hoersken wrote:
> 2012/11/4 Oscar Koeroo <okoeroo_at_nikhef.nl>:
> I don't know, I copied this specific check from another curl SSL backend.

I've seen the same checks, but different motivations:

- Post connection verification based on SubjectAltNames IP
  instead of DNS; OpenSSL.
- Enabling SNI; OpenSSL, GnuTLS, PolarSSL, Darwin
- Disabling SNI; Schannel (accoording to the tekst)

Side note: currently not using SNI from cUrl, but the SSL libs are capable
of setting the extension are: CyaSSL, axTLS and NSS.

> Sure, but there should be a way to ignore this and still setup the connection.

I concur. Overrides are simply needed.

> Please make sure that you test that Schannel is actually able to
> handle IP addresses before removing this check.

Yes, I've adjusted the code in Schannel to split the SNI disabling and
'VERIFYHOST < 2' part. I will not remove this stuff without proper testing.
I currently don't have a development environment to test any of these
annomolies.

> I think SNI is supported in Schannel since Windows XP SP3, but I am
> testing on Windows 7.

I couldn't find these details on the client side. I'm hitting the server
side support pages it seems.

>> I hope you can dig up info about this. This is interesting stuff as SNI
>> becomes popular.
>
> Attached you will find a small Wireshark dump containing two Client
> Hello packets. Once SCH_CRED_NO_SERVERNAME_CHECK is supplied to
> Schannel it does not send the server_name extension and therefore
> disables SNI. This makes sense since Schannel will not care about the
> server name, why should it bother sending it in the first place?

Thank you! To me this feels like quite an implementation difference between
Schannel and other SSL libraries. Also I think MSDN should've indicated the
SNI (side?) effect when SCH_CRED_NO_SERVERNAME_CHECK.

Example scenario:
1. connect to picard.example.org with TLS 1.1 or 1.2
2. I set VerifyHost to 0, this setting SCH_CRED_NO_SERVERNAME_CHECK

In this example I would expect the Schannel to connect me to the
picard.example.org host, push the SNI info, get the certificate for
picard1.example.org virtual host (for example) and happily ignore the
mismatch. If SNI gets disabled I will be treated differently on that host
and get a different certificate.

Bottomline: if you desire to disable SNI and/or connect with an IP address
(not explicitly covered by RFC2818 anyway) then you'll have to disable host
verification in Schannel all together. I more fine grained option in
Schannel would've made this more transparent instead of the current situation.

I will change the cUrl patch regarding Schannel to give a more transparent
hint based on your findings.

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