crypto/tls: implement OCSP Must-Staple

[nhooyr]

A bit over a year ago, someone created an issue to add support for RFC 7633 TLS Feature Extension into crypto/tls but it was closed by @agl because he felt it was premature and that OCSP stapling wasn't really supported as a client in Go (not sure if that has changed?).

See #13074

It's been more than a year so I'm creating this issue to see what he thinks of it now.

[odeke-em]

Another one for you s'il vous plait @agl.

[agl]

Firstly, there's nothing stopping you from using ExtraExtensions and Extensions to implement this if you wish in crypto/x509, the question is really whether OCSP stapling, must-staple etc should be wound throughout the code. Probably as both a client and server if we're going to do a good job of it.

Firefox supports must-staple now and Chrome has Expect-stable support. I think Cloudflare have it on blog.cloudflare.com.

So it's plausible, but a bigger job than can reasonably happen in the 1.10 cycle.

[ianlancetaylor]

Proposal accepted based on @agl's comment. Please go ahead and send in an implementation.

[FiloSottile]

Retitled to reflect that this is about implementing OCSP Must-Staple across crypto/tls and crypto/x509.

[divjotarora]

@FiloSottile @agl Until this is done, what are my options to perform OCSP verification in a client (non-HTTP client, if that matters). For my use case, I need to be able to determine whether or not the certificate presented by the server has a Must-Staple extension, the stapled response returned by the server, if any, and the OCSP responder endpoint for the certificate presented by the server.

I've seen two recommended options so far:

1. Use the VerifyPeerCertificate callback in the tls.Config. I like this idea because crypto/tls will abort the handshake and report a proper error if OCSP verification fails, but I cannot figure out how to access the server's stapled OCSP response.

2. Let the handshake complete normally and then use the tls.Conn.ConnectionState method to access the ConnectionState, which has the certificate chain presented by the server and the stapled OCSP response. I saw this approach in this talk. It could work, but it might report that the handshake has been successfully completed in server logs.

Any suggestions?

[rolandshoemaker]

Randomly stumbled across this and thought it might be an interesting issue to tackle (that is if nobody else is already working on it!).

It seems like there are two real units of work here:

1. in crypto/tls on the client side enforcing that if the presented leaf certificate contains a tls feature extension with status_request that the ServerHello message contained an OCSP response in the certificate status message, and perhaps adding some safeguards to the server side so you can't present a cert containing the extension if you haven't provided a OCSP response.
2. in crypto/x509 adding OCSP response validation, probably to Certificate.Verify.

Support for RFC 7633 can be added by just accomplishing (1), but that ends up off-loading significant responsibility to the user who might not really be paying attention. On the other hand bundling the two changes together makes a significantly more complex changeset.

[rolandshoemaker]

Actually (2) probably doesn't make much sense, the existing x/crypto/ocsp logic can just be called directly from crypto/tls (and trying to introduced that into crypto/x509 would create a fun circular dependency anyway). Overall that makes the change somewhat less complicated.

[ancarda]

Firstly, there's nothing stopping you from using ExtraExtensions and Extensions to implement this if you wish

Would anyone be open to a patch to crypto/x509 that checks for this extension and exposes it as a bool in the Certificate struct? Kinda like IsCA, but for checking if OCSP Must Staple is set?

type Certificate struct {
    ...
    // If this certificate requires OCSP Stapling.
    MustStapleOCSP bool
    ...
}

It seems a lot easier than checking for the extension by its ID.