libcurl + winssl = https not working on Windows 2000 about curl

[bagder]

@mback2k seen anything like this before?

[jay]

This issue came up on the list several years ago, see http://curl.haxx.se/mail/lib-2012-06/0283.html

I echo Mark's 2012 sentiments. The documentation seems sparse, but I found it discussed in Generating the Digest Challenge Response, specifically Quality of Protection, where it says:

The quality of protection, identified by the qop directive, is first specified by the server in the Digest challenge, and then confirmed by the client in the challenge response. If the client requires a quality of protection that the server does not support, the client must terminate the authentication.

Mystery of course is why the server doesn't support those things, but only certain older algorithms and protocols are enabled in Win2k by default so I'll speculate that it might be the client and server just don't share anything in common anymore.

@zenden2k Can you access any https website successfully using that version of curl in Windows 2000? Can you access https://google.com in Internet Explorer?

[zenden2k]

Can you access any https website successfully using that version of curl in Windows 2000?

no

Can you access https://google.com in Internet Explorer?

yes, but most of https sites do not work in internet explorer,

F:\image-uploader\Dist>curl -v https://yandex.com
* Rebuilt URL to: https://yandex.com/
*   Trying 213.180.204.62...
* Connected to yandex.com (213.180.204.62) port 443 (#0)
* schannel: SSL/TLS connection with yandex.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 70 bytes...
* schannel: sent initial handshake data: sent 70 bytes
* schannel: SSL/TLS connection with yandex.com port 443 (step 2/3)
* schannel: failed to receive handshake, need more data
* schannel: SSL/TLS connection with yandex.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 3113 length 4096
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) -
 The revocation function was unable to check revocation because the revocation server was offline.
.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with yandex.com port 443
* schannel: clear security context handle
* schannel: clear credential handle
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x800
92013) -  The revocation function was unable to check revocation because the revocation server was offline. 

[zenden2k]

It is not important issue for me because I drop win 2000 support in my program.

Anyway, there is something wrong in curl winssl implementation.
Also it doesn't work with Fiddler Web Debugging Proxy with HTTPS decryption enabled (tested on Windows 8.1)

WinSSL:

>curl.exe -v -x 127.0.0.1:8888 https://google.com
* Rebuilt URL to: https://google.com/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.40.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection Established
< FiddlerGateway: Direct
< StartTime: 22:42:05.973
< Connection: close
<
* Proxy replied OK to CONNECT request
* schannel: SSL/TLS connection with google.com port 443 (step 1/3)
* schannel: checking server certificate revocation
* schannel: sending initial handshake data: sending 179 bytes...
* schannel: sent initial handshake data: sent 179 bytes
* schannel: SSL/TLS connection with google.com port 443 (step 2/3)
* schannel: encrypted data buffer: offset 1173 length 4096
* schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) -
The revocation function was unable to check revocation for the certificate.
* Closing connection 0
* schannel: shutting down SSL/TLS connection with google.com port 443
* schannel: clear security context handle
* schannel: clear credential handle
curl: (35) schannel: next InitializeSecurityContext failed: Unknown error (0x800
92012) - The revocation function was unable to check revocation for the certificate.

Fiddler proxy with openssl:

c:\Programs>curl.exe -v -x 127.0.0.1:8888 https://google.com
* Rebuilt URL to: https://google.com/
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 8888 (#0)
* Establish HTTP proxy tunnel to google.com:443
> CONNECT google.com:443 HTTP/1.1
> Host: google.com:443
> User-Agent: curl/7.41.0
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 Connection Established
< FiddlerGateway: Direct
< StartTime: 22:48:36.062
< Connection: close
<
* Proxy replied OK to CONNECT request
* successfully set certificate verify locations:
*   CAfile: c:\Programs\curl-ca-bundle.crt
  CApath: none
* TLSv1.2, TLS handshake, Client hello (1):
* TLSv1.2, TLS handshake, Server hello (2):
* TLSv1.2, TLS handshake, CERT (11):
* TLSv1.2, TLS handshake, Server key exchange (12):
* TLSv1.2, TLS handshake, Server finished (14):
* TLSv1.2, TLS handshake, Client key exchange (16):
* TLSv1.2, TLS change cipher, Client hello (1):
* TLSv1.2, TLS handshake, Finished (20):
* TLSv1.2, TLS change cipher, Client hello (1):
* TLSv1.2, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-SHA384
* Server certificate:
*        subject: OU=Created by http://www.fiddler2.com; O=DO_NOT_TRUST; CN=goog
le.com
*        start date: 2014-05-08 21:00:00 GMT
*        expire date: 2025-05-08 20:59:59 GMT
*        common name: google.com (matched)
*        issuer: OU=Created by http://www.fiddler2.com; O=DO_NOT_TRUST; CN=DO_NO
T_TRUST_FiddlerRoot
*        SSL certificate verify ok.
> GET / HTTP/1.1
> User-Agent: curl/7.41.0
> Host: google.com
> Accept: */*
>
< HTTP/1.1 301 Moved Permanently
< Location: https://www.google.com/
< Content-Type: text/html; charset=UTF-8
< Date: Sun, 10 May 2015 19:48:42 GMT
< Expires: Tue, 09 Jun 2015 19:48:42 GMT
< Cache-Control: public, max-age=2592000
< Server: gws
< Content-Length: 220
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
<
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>301 Moved</TITLE></HEAD><BODY>
<H1>301 Moved</H1>
The document has moved
<A HREF="https://www.google.com/">here</A>.
</BODY></HTML>
* Connection #0 to host 127.0.0.1 left intact

[jay]

Thanks for the extra information. I'll try to get in a Win2k vm and do some investigation.

As for your second problem with Fiddler that's a separate issue, so please file it separately. I can reproduce using curl 7.42.1 x86 WinSSL WinIDN. As a workaround you can specify the -k option to allow insecure connections which also disables revocation checking. I caution you only do that if you are connecting to the localhost Fiddler proxy and have HTTPS intercept enabled. The connection between Fiddler and the destination website will still be verified by Fiddler, but curl will no longer validate the certificate supplied by Fiddler to curl.

[jay]

I went as far back as curl-7_27_0 (about 2012) trying to find a good commit so that I could bisect. winbuild doesn't work for building using schannel/WinSSL before then. Unfortunately I couldn't find a commit where the attempt at an SSL connection didn't cause some type of error in Win2k. I tried:

curl -v https://google.com
curl -v https://microsoft.com
curl -v https://test.com

Does anyone recall when the last time was that curl worked in Win2k?

Does anyone know of any legacy SSLv3 servers that would be good for testing with curl in Win2k?

[jay]

I've also tried enabling TLS 1.0 and enabling schannel info logging. There's nothing helpful in the system log. Wireshark shows this:

Secure Sockets Layer
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 53
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 49
            Version: TLS 1.0 (0x0301)
            Random
            Session ID Length: 0
            Cipher Suites Length: 10
            Cipher Suites (5 suites)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_RC4_56_SHA (0x0064)
                Cipher Suite: TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x0062)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC4_40_MD5 (0x0003)
                Cipher Suite: TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 (0x0006)
                Cipher Suite: TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA (0x0063)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)

the reply from google.com:

Secure Sockets Layer
    TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: TLS 1.0 (0x0301)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

I tried in IE5 as well just to see what would happen. The client hello is slightly different (SSLv2) and there's still a handshake failure.

@zenden2k I've moved your report about Fiddler to #264.

[jay]

@mback2k Would you mind taking a look at this? I think a client in Win2k using its native WinSSL backend is at this point just too old to interact with most servers. It's nagging me though how the reporter is able to connect to yandex and I can't, like maybe I misconfigured something. What can be done here, maybe a warning in Win2k (and possibly XP soon) if we see the connection fail curl will show a special message explaining what's likely happened.

[bagder]

Based on the results from all his, we can also consider documenting (somewhere) a "lowest advisable windows version" to use for native winssl builds.

[jay]

Alright that's a better idea, I noted it in the documentation in 6842afb. Also I have a PR in curl-www to add a footnote to ssl-compared. I think we should be good for now but I'll leave this for Marc to close.

[mback2k]

@jay Please keep in mind that service packs and patches also influence the available cipher suites. This might be the reason why you cannot connect to Yandex and the original reporter can. It also looks like your Windows 2000 only supports export cipher modes. So it might be something related to the local of the Windows installation.

[bagder]

@mback2k you think any of those are reasons enough to change anything here or can we close it?