On 04-11-12 09:10, Marc Hoersken wrote:
> 2012/11/4 Oscar Koeroo <okoeroo_at_nikhef.nl>
>> lib/curl_schannel.c
>> VerifyHost is not used
>
> I don't think this is correct. Please see line 163.

You are right! It's indeed used. This is a silly mistake because I'm quoting
the section that it uses it in my email...

>> It's RFC2818 compliant out of the box, like NSS. It's the only SSL
>> security
>> opt-out SSL interface I've seen. To switch it off you'll need to set the
>> flag SCH_CRED_NO_SERVERNAME_CHECK according to
>> http://msdn.microsoft.com/en-us/library/aa923430.aspx :
>
> Yes, and that is actually done for IP addresses and if verifyhost is
> smaller than 2.

Yes, this part I understand. If you detect it's an IP, don't bother to do
the verification. This is something which is covered internally in other SSL
stacks. Does this mean that the Schannel library will fail to connect if
there are Subject Alt Names IP-addresses in the certificate?

I think it's totally normal to not succeed setting up an SSL connection if
there is no way you can compare binding information of the certificate in
the SSL handshake and the underlying transport layer.

The code snippet disables a check with a SubjectAltNames IP-address which
might be supported by the Schannel library and/or used in a host certificate
in deployments.

I'm inclined to remove the check on IP-address input in cUrl around this
part because I think cUrl should simply not be responsible for this choice.

>> 159 if(Curl_inet_pton(AF_INET, conn->host.name, &addr) ||
>> 160 #ifdef ENABLE_IPV6
>> 161 Curl_inet_pton(AF_INET6, conn->host.name, &addr6) ||
>> 162 #endif
>> 163 data->set.ssl.verifyhost < 2) {
>> 164 schannel_cred.dwFlags |= SCH_CRED_NO_SERVERNAME_CHECK;
>> 165 infof(data, "schannel: using IP address, disable SNI servername
>> "
>> 166 "check\n");
>> 167 }
>>
>> Note: The info statement of SNI is wrong, it should've said SAN or
>> something
>> related to the common name and/or subject alt names.
>
> You may want to look at the context of the name checks being disabled.
> SCH_CRED_NO_SERVERNAME_CHECK also disables SNI and that is required
> for IP address based connections without a DNS name. Of course the
> info statement could include the general fact that name validation is
> completely disabled, too. But it's not "wrong".

Do you have documentation backing up this part?

Quoting
http://msdn.microsoft.com/en-us/library/windows/desktop/aa379810%28v=vs.85%29.aspx
it says:

"SCH_CRED_NO_SERVERNAME_CHECK: Client only. Prevent Schannel from comparing
the supplied target name with the subject names in server certificates."

If I Google the SCH_CRED_NO_SERVERNAME_CHECK with the term SNI I only get
cUrl code and maillist hits. Nothing on the SNI (Server Name Indication)
side effect here too
http://msdn.microsoft.com/en-us/library/aa923156.aspx

I don't have a Windows Server 2012 (which seems to introduce TLS support for
Server Name Indicator (SNI) extensions:
http://technet.microsoft.com/en-us/library/hh831381.aspx) to play with to
Wireshark it to confirming the SCH_CRED_NO_SERVERNAME_CHECK. I doubt this is
really what is going on in Schannel.

I hope you can dig up info about this. This is interesting stuff as SNI
becomes popular.

        Oscar

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