-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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: add Config.VerifyConnection callback #36736
Comments
I'm afraid you are correct. I can only think of two solutions, both not great: adding a new callback, or adding a global map accessible via something like |
@FiloSottile I think of those two suggestions, I'd prefer the additional callback. Also, is it a viable solution to deprecate |
While not solving the specific problem of not having access to the stapled response in |
@rolandshoemaker This is fair, but just adding support for MustStaple verification does not necessarily address all use cases. For example, my use case requires me to manually reach out to an OCSP responder via an HTTP request if the certificate is not a MustStaple cert and a staple is not provided. Having access to the OCSP response inside a callback like |
@katiehockman pointed out that ConnectionState already has all the information needed to verify a peer, and semantically I don't see how we would want things in VerifyPeerCertificate but not in ConnectionState, and vice-versa. Taking the opportunity to make the semantics of when the callback is invoked more straightforward, we propose this callback.
While at it, I propose we set An open question is whether we should allow setting both |
Particularly happy about how easy it makes reproducing (and then customizing) normal verification.
|
Is the proposal now to add VerifyConnection, not "provide access to stapled OCSP response in VerifyPeerCertificate"? |
@rsc that's correct. The proposal is for a new callback, |
@katiehockman Will this also involve deprecating the existing |
@divjotarora no I don't expect
|
@FiloSottile @katiehockman As part of this, would it be possible to improve some of the documentation for the
which makes it sound like I can't assume this? Some documentation improvements to explicitly state what each chain in |
@divjotarora Very happy to make such usability changes. Could you open a new issue for it so we don't lose track of it? |
@FiloSottile Thanks for the quick response! I filed #37572. Would you be able to answer my question about |
Marking this discussion ongoing for the proposal minutes, but it seems like we're headed toward a likely accept. I just want to be sure to let the discussion finish. |
Based on the discussion above, this seems like a likely accept. |
No change in consensus, so accepted. |
To @katiehockman for implementation. Reminder that we decided to also set |
Change https://golang.org/cl/229122 mentions this issue: |
Change https://golang.org/cl/239560 mentions this issue: |
Look at how much better it is! Updates #36736 Change-Id: I53a314a103a42dd869c05823fa50f37d70f9d283 Reviewed-on: https://go-review.googlesource.com/c/go/+/239560 Run-TryBot: Filippo Valsorda <filippo@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Katie Hockman <katie@golang.org>
I'd like to do OCSP verification using the
VerifyPeerCertificate
field oftls.Config
. My understanding is that it is not possible to access the stapled OCSP response from the peer in this callback. This is because the stapled response is available on the connection itself through theOCSPResposne
method ontls.Conn
or through theConnectionState
type. Unless there is a way to access it in the callback, the OCSP verification will have to be done after the handshake has been completed, which isn't ideal because the peer logs will show that the connection was successfully established.Is there a way to currently access the stapled responses in the verification callback that I've missed? If not, is this possible given how the TLS handshake code is currently written?
The text was updated successfully, but these errors were encountered: