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

Jump to bottom

crypto/tls: optional ocspStapling #8549

Closed
brad-burch opened this issue Aug 19, 2014 · 9 comments
Closed

crypto/tls: optional ocspStapling #8549

brad-burch opened this issue Aug 19, 2014 · 9 comments
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Milestone
Go1.11

Comments

@brad-burch
Copy link
Contributor 

go version go1.3

I have a server outside my control that fails to respond properly when OSCP stapling is
enabled and causes a "tls: received unexpected handshake message..." error.

I would like to be able to set a tls.Config{} option to disable OSCP stapling instead of
recompiling the package.  I am attaching the rudimentary patch I have been compiling
into crypto/tls.

Attachments:

  1. DisableOSCPStapling.patch (1166 bytes)
@griesemer
Copy link
Contributor

Comment 1:

Labels changed: added release-none, repo-crypto.

@brad-burch
Copy link
Contributor Author

go version go1.4rc2

Attaching a different patch which resolves my issue and follows the wording in RFC4366 more precisely.

https://gist.github.com/brad-burch/148a7dfe258c3e6fd68f

@brad-burch brad-burch changed the title crypto/tls: disabling ocspStapling crypto/tls: optional ocspStapling Dec 9, 2014
@bradfitz bradfitz removed the new label Dec 18, 2014
@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@x1ddos x1ddos mentioned this issue Nov 3, 2016
Closed
@mberhault
Copy link

Any movement on this? It has caused some confusion on this stack overflow question. Given that the patch proposes to accurately implement the RFC, is there any downside in integrating it?

@bradfitz
Copy link
Contributor

bradfitz commented Jan 3, 2018

@mberhault, any movement would be reflected in this bug, so I would say there's been no movement. And no patch was formally sent via https://golang.org/doc/contribute.html

@agl, any opinion on making OCSP stapling optional?

@bradfitz bradfitz added the NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made. label Jan 3, 2018
@bradfitz bradfitz modified the milestones: Unplanned, Go1.11 Jan 3, 2018
@agl
Copy link
Contributor

agl commented Jan 3, 2018

We don't want to accrete lots of options to work around buggy servers. OCSP stapling isn't obscure or anything.

@mberhault
Copy link

The updated patch (not the original) is about properly handling a certificateStatusMsg response as optional, it no longer changes tls.Config.
I can't claim to be that knowledgeable about OCSP stapling, but the quoted RFC section seems to justify the change.

@agl
Copy link
Contributor

agl commented Jan 3, 2018

Ah, I see. The CertificateStatus message being optional is a mistake in the spec, but it is in the spec. I don't want to look at a patch that isn't CLAed, but it sounds perfectly reasonable. (Possibly for 1.10, even.)

@mberhault
Copy link

mberhault commented Jan 3, 2018 •
edited

Sounds reasonable. @brad-burch: would you mind taking your patch through https://golang.org/doc/contribute.html?

@gopherbot
Copy link

Change https://golang.org/cl/86115 mentions this issue: crypto/tls: optional "certificate_status" with OCSP

FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
@brad-burch @agl
crypto/tls: optional "certificate_status" with OCSP
6489cd9 
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes golang#8549

Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
@brad-burch @kriskwiatkowski
crypto/tls: optional "certificate_status" with OCSP
0957fdb 
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes golang#8549

Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
@brad-burch @kriskwiatkowski
crypto/tls: optional "certificate_status" with OCSP
f1a5602 
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes golang#8549

Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
FiloSottile pushed a commit to FiloSottile/go that referenced this issue Oct 12, 2018
@brad-burch @agl
crypto/tls: optional "certificate_status" with OCSP
1ecb374 
Follows the wording in RFC4366 more precisely which allows a server
to optionally return a "certificate_status" when responding to a
client hello containing "status_request" extension.

fixes golang#8549

Change-Id: Ib02dc9f972da185b25554568fe6f8bc411d9c0b7
Reviewed-on: https://go-review.googlesource.com/86115
Reviewed-by: Adam Langley <agl@golang.org>
@golang golang locked and limited conversation to collaborators Jan 4, 2019
@rsc rsc unassigned agl Jun 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsDecision Feedback is required from experts, contributors, and/or the community before a change can be made.
Projects
None yet
Milestone
Go1.11
Development

No branches or pull requests
8 participants
@bradfitz @agl @mikioh @rsc @brad-burch @mberhault @griesemer @gopherbot