Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

libcurl+schannel reports different error code across versions for verify peer/host options #6003

Closed
iammrtau opened this issue Sep 23, 2020 · 4 comments
Labels
TLS Windows Windows-specific

Comments

@iammrtau
Copy link

I did this

I have a server with custom ssl certificate that can be connected with curl by passing 0 to both methods below, but the problem arises when the following code is used -

curl_easy_setopt(curl_object, CURLOPT_SSL_VERIFYPEER, 1L);
curl_easy_setopt(curl_object, CURLOPT_SSL_VERIFYHOST, 2L);

This used to give error code 60 in 7.56 and I've tested in 67,71 and now 72 versions, all of which have changed this to give error 35. 35 - CURLE_SSL_CONNECT_ERROR and 60 - CURLE_PEER_FAILED_VERIFICATION. The error 60 was preferred because it is more clear and unique to this situation while error 35 also results sometimes when there is a firewall or proxy breaking connections in between.

Keeping my code exactly similar and the process I build is same, just changing between 7.56 and 7.72 results in two different error codes. Meanwhile all versions under linux and osx continue to work fine and give error code 60.

curl/libcurl version

It was fine till 7.56 and I'm not sure which version bug started with but the earliest I know is 7.67

[curl -V output]
I hope this is asking about the built version(the one I use libcurl libraries with)

curl 7.72.0 (i386-pc-win32) libcurl/7.72.0 Schannel zlib/1.2.11 WinIDN
Release-Date: 2020-08-19
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Kerberos Largefile NTLM SPNEGO SSL SSPI UnixSockets libz

operating system

Windows 10 Pro (version 2004)

@bagder bagder added TLS Windows Windows-specific labels Sep 23, 2020
@bagder bagder changed the title libcurl reports different error code across versions for verify peer/host options libcurl+schannel reports different error code across versions for verify peer/host options Sep 23, 2020
@bagder
Copy link
Member

bagder commented Sep 23, 2020

I can't find any obvious error like this when reading the lib/vtls/schannel.c code.

What does a VERBOSE log show? What does ERRORBUFFER contain after CURLE_SSL_CONNECT_ERROR is returned for you?

How can we reproduce this issue?

@iammrtau
Copy link
Author

I compiled 7.56.1 and 7.72.0 versions of curl, kept everything same in my project and rebuilt two separate applications for respective versions. Here are the logs -

Info: [CURL] 	Trying x.x.x.x...
Info: [CURL] 	TCP_NODELAY set
Info: [CURL] 	Connected to domain.com (x.x.x.x) port 443 (#0)
Info: [CURL] 	schannel: SSL/TLS connection with domain.com port 443 (step 1/3)
Info: [CURL] 	schannel: disabled server certificate revocation checks
Info: [CURL] 	schannel: sending initial handshake data: sending 212 bytes...
Info: [CURL] 	schannel: sent initial handshake data: sent 212 bytes
Info: [CURL] 	schannel: SSL/TLS connection with domain.com port 443 (step 2/3)
Info: [CURL] 	schannel: failed to receive handshake, need more data
Info: [CURL] 	schannel: SSL/TLS connection with domain.com port 443 (step 2/3)
Info: [CURL] 	schannel: encrypted data got 1120
Info: [CURL] 	schannel: encrypted data buffer: offset 1120 length 4096
Info: [CURL] 	schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
Info: [CURL] 	Closing connection 0
Info: [CURL] 	schannel: shutting down SSL/TLS connection with domain.com port 443
Info: [CURL] 	schannel: clear security context handle
Info: [ERROR_BUFFER] 	 schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted. 
Info: [HttpClient] curlresultcode: 60
Info: [HTTP]  curl_easy_perform() failed: %s Peer certificate cannot be authenticated with given CA certificates 
Info: [CURL] 	Trying x.x.x.x:443...
Info: [CURL] 	Connected to domain.com (x.x.x.x) port 443 (#0)
Info: [CURL] 	schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted.
Info: [CURL] 	Closing connection 0
Info: [CURL] 	schannel: shutting down SSL/TLS connection with domain.com port 443
Info: [ERROR_BUFFER] 	 schannel: next InitializeSecurityContext failed: SEC_E_UNTRUSTED_ROOT (0x80090325) - The certificate chain was issued by an authority that is not trusted. 
Info: [HttpClient] curlresultcode: 35
Info: [HTTP]  curl_easy_perform() failed: %s SSL connect error 

@iammrtau
Copy link
Author

I think you won't need logs for linux systems since this problem seems to be windows specific but here is what error buffer contains in linux -

Info: [ERROR_BUFFER] t SSL certificate problem: self signed certificate 

@bagder
Copy link
Member

bagder commented Sep 28, 2020

I believe it came with this commit: 5a3efb1 shipped in 7.62.0. I think we can/should bring back the CURLE_PEER_FAILED_VERIFICATION return code for the schannel error SEC_E_UNTRUSTED_ROOT. I'll submit a PR in a sec.

@bagder bagder removed the needs-info label Sep 28, 2020
bagder added a commit that referenced this issue Sep 28, 2020
This matches what is returned in other TLS backends in the same
situation.

Follow-up to 5a3efb1
Reported-by: iammrtau on github
Fixes #6003
bagder added a commit that referenced this issue Sep 28, 2020
This matches what is returned in other TLS backends in the same
situation.

Follow-up to 5a3efb1
Reported-by: iammrtau on github
Fixes #6003
@bagder bagder closed this as completed in abeeffb Sep 28, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
TLS Windows Windows-specific
Development

Successfully merging a pull request may close this issue.

2 participants