Following #3727 and #264 --ssl-no-revoke, I would like to implement, but before I want your opinion if it would be a good idea or not.
Problem
On Windows with Schannel, when:
- proxies are used
- firewalls block access to all other IPs apart from the proxy
- and curl is call by a Windows service (using the local system account)
As a result:
Curl can connect to the proxy, but Schannel attempts to access the CRL endpoint directly because it is not aware of the proxy configuration.
The problem is that Schannel will use the WinHTTP proxy and not the WinInet defined proxy and because direct access is blocked the request will fail with a schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate. error when curl is running within a service context which is probably caused by a destination unreachable error.
This is usually not a problem when the proxies do SSL inspection, as they are most likely to serve an SSL certificate that doesn't have a CRL distribution endpoint, but it's not guaranteed.
Proposed solution
The existing options --ssl-no-revoke or CURLSSLOPT_NO_REVOKE will just work fine. In addition to these we could add an extra option to give more flexibility to users.
The new option:
- Cloud be called
--ssl-ignore-revoke-offline and CURLSSLOPT_IGNORE_REVOKE_OFFLINE and will use the SCH_CRED_IGNORE_NO_REVOCATION_CHECK flag on Schannel
- Will instruct Schannel to ignore blocked access or temporary unavailability of the CRL server
- The default behaviour of the library will be the same as today and users have to enable the behaviour explicitly.
- Changes should be very similar to 172b2be
The benefits will be that Windows can attempt to perform the revocation check and if it fails constantly on proxied environments the requests will succeed and security will be considered at the proxy or firewall level.
Before I start writing any code, I would be thankful if more experienced users have a think about this and feedback if it would be a good idea or not.
Following #3727 and #264
--ssl-no-revoke, I would like to implement, but before I want your opinion if it would be a good idea or not.Problem
On Windows with Schannel, when:
As a result:
Curl can connect to the proxy, but Schannel attempts to access the CRL endpoint directly because it is not aware of the proxy configuration.
The problem is that Schannel will use the WinHTTP proxy and not the WinInet defined proxy and because direct access is blocked the request will fail with a
schannel: next InitializeSecurityContext failed: Unknown error (0x80092012) - The revocation function was unable to check revocation for the certificate.error when curl is running within a service context which is probably caused by adestination unreachableerror.This is usually not a problem when the proxies do SSL inspection, as they are most likely to serve an SSL certificate that doesn't have a CRL distribution endpoint, but it's not guaranteed.
Proposed solution
The existing options
--ssl-no-revokeorCURLSSLOPT_NO_REVOKEwill just work fine. In addition to these we could add an extra option to give more flexibility to users.The new option:
--ssl-ignore-revoke-offlineandCURLSSLOPT_IGNORE_REVOKE_OFFLINEand will use the SCH_CRED_IGNORE_NO_REVOCATION_CHECK flag on SchannelThe benefits will be that Windows can attempt to perform the revocation check and if it fails constantly on proxied environments the requests will succeed and security will be considered at the proxy or firewall level.
Before I start writing any code, I would be thankful if more experienced users have a think about this and feedback if it would be a good idea or not.