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

crypto/tls: implement OCSP Must-Staple #22274

Open
nhooyr opened this issue Oct 14, 2017 · 7 comments
Open

crypto/tls: implement OCSP Must-Staple #22274

nhooyr opened this issue Oct 14, 2017 · 7 comments

Comments

@nhooyr
Copy link
Contributor

@nhooyr nhooyr commented Oct 14, 2017

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 odeke-em changed the title crypto/tls: Implement RFC 7633 TLS Feature Extension Proposal: crypto/tls: Implement RFC 7633 TLS Feature Extension Oct 14, 2017
@gopherbot gopherbot added this to the Proposal milestone Oct 14, 2017
@gopherbot gopherbot added the Proposal label Oct 14, 2017
@odeke-em

This comment has been minimized.

Copy link
Member

@odeke-em odeke-em commented Oct 14, 2017

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

@agl

This comment has been minimized.

Copy link
Contributor

@agl agl commented Oct 14, 2017

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

This comment has been minimized.

Copy link
Contributor

@ianlancetaylor ianlancetaylor commented Mar 19, 2018

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

@ianlancetaylor ianlancetaylor modified the milestones: Proposal, Unplanned Mar 19, 2018
@FiloSottile FiloSottile changed the title Proposal: crypto/tls: Implement RFC 7633 TLS Feature Extension crypto/tls: implement OCSP Must-Staple Jan 21, 2020
@FiloSottile

This comment has been minimized.

Copy link
Member

@FiloSottile FiloSottile commented Jan 21, 2020

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

@divjotarora

This comment has been minimized.

Copy link

@divjotarora divjotarora commented Jan 23, 2020

@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

This comment has been minimized.

Copy link

@rolandshoemaker rolandshoemaker commented Feb 14, 2020

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

This comment has been minimized.

Copy link

@rolandshoemaker rolandshoemaker commented Feb 14, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
8 participants
You can’t perform that action at this time.