proposal: crypto/tls: Config.VerifyOptions option to disable certificate revocation check

[solvingj]

Proposal: Add tls.Config/VerifyOptions option to disable certificate revocation check

Background

Since #46287 , Go defaults to the the system verifier on Windows and macOS.

Windows automatically blocks to perform real-time revocation checking (CRL/OCSP) which is effectively instantaneous under normal circumstances. However, in airgapped environments, or enterprise networks which don't allow outbound HTTP/HTTPS to "any destination", the revocation runs for 15 to 20 seconds, or longer depending on the systems chain. In these situations, it exceeds the Go net/http default TLS handshake timeout of 10 seconds, leading to net/http: TLS handshake timeout error.

The popular web client curl identified the same problem on windows and introduced a dedicated flag to disable revocation checking:
"SSL: Add an option to disable certificate revocation checks". (--ssl-no-revoke)
curl/curl@172b2be

Proposal

Add a new boolean field:

• InsecureSkipRevocation to crypto/tls.Config
• InsecureSkipRevocation to crypto/x509.VerifyOptions

Example API

type tls.Config struct {
    ...
    // InsecureSkipRevocation disables certificate revocation checking.
    // WARNING: Disabling revocation checking weakens TLS security.
    InsecureSkipRevocation bool
    ...
}

type x509.VerifyOptions struct {
    ...
    // InsecureSkipRevocation disables certificate revocation checking.
    InsecureSkipRevocation bool
    ...
}

When set, platforms capable of disabling revocation checking (e.g., Windows via Schannel) will skip CRL/OCSP checks during chain validation.

If approved, this proposal can be amended to include the more complete implementation.

[rbqvq]

I have some suggestions for this.

For tls.Config fields is InsecureSkipRevocation (just like InsecureSkipVerify)

[solvingj]

I have some suggestions for this.

For tls.Config fields is InsecureSkipRevocation (just like InsecureSkipVerify)

Updated description

[DanielMorsing]

I think you're able to get your desired behavior by using tls.Config.VerifyPeerCertificates and manually calling into crypto/x509 for verification.

It's a shame that the revocation behavior isn't consistent across platforms. Given the push to shorter certificate validity and how infrequent CRLs actually seem to work in practice (see CRLSets and CRLite as examples of workarounds for this fact), it might be worth it to configure the system verifiers to not check for revocation, but more security-minded people may disagree with me

[mcpherrinm]

It's a shame that the revocation behavior isn't consistent across platforms.

Having Go call into the system verifier is important for making features like CRLite work. With Linux getting support for this (https://discourse.ubuntu.com/t/addressing-linuxs-missing-pki-infrastructure/73314), hopefully things will start becoming more consistent and check revocation on major platforms.

I think that's also a good argument to add a cross-platform way to disable revocation checks without having to reimplement a VerifyPeerCertificates function