zenden2k reported curl with WinSSL backend can't connect to Fiddler proxy if HTTPS intercept is enabled.
>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.
schannel is returning CRYPT_E_NO_REVOCATION_CHECK likely because we pass SCH_CRED_REVOCATION_CHECK_CHAIN in schannel_connect_step1 and in that case schannel requires all root CAs to have some sort of revocation detail when that flag is passed. Fiddler doesn't, so it fails? @ericlaw1979
Assuming that's the case it should be sufficient to advise in the FAQ or wiki or somewhere that if curl with WinSSL backend is used to connect to a Fiddler proxy with HTTPS intercept enabled that the -k option should be passed to curl so it does not attempt to verify Fiddler's certificate. A caution could be added to only do that if the Fiddler proxy is on localhost and only if HTTPS intercept is enabled.
Another way to go would be offer a way to disable revocation checking for WinSSL and advise Fiddler users pass that switch.
Thoughts?
zenden2k reported curl with WinSSL backend can't connect to Fiddler proxy if HTTPS intercept is enabled.
schannel is returning
CRYPT_E_NO_REVOCATION_CHECKlikely because we passSCH_CRED_REVOCATION_CHECK_CHAINinschannel_connect_step1and in that case schannel requires all root CAs to have some sort of revocation detail when that flag is passed. Fiddler doesn't, so it fails? @ericlaw1979Assuming that's the case it should be sufficient to advise in the FAQ or wiki or somewhere that if curl with WinSSL backend is used to connect to a Fiddler proxy with HTTPS intercept enabled that the
-koption should be passed to curl so it does not attempt to verify Fiddler's certificate. A caution could be added to only do that if the Fiddler proxy is on localhost and only if HTTPS intercept is enabled.Another way to go would be offer a way to disable revocation checking for WinSSL and advise Fiddler users pass that switch.
Thoughts?