Closed rogpeppe closed 8 years ago
> Really don't ever want to support this. TLS renegotiation is a huge mess. That's a pity, although I do understand. It seems we're ending up using http://godoc.org/github.com/andelf/go-curl which is a) a pretty messy package and b) a cgo dependency we could do without. Have you got a suggestion for a neater way around the issue, by any chance?
I am creating a Packer plugin for the Microsoft Azure services but I am getting a "local error: no renegotiation" error message when I make the client.Do(req) after setting up the transport to use my client certificate. I am using Go version 1.2.1. Am I understanding this issue correctly in that 1.2.1 is not be able to to talk to Microsoft Azure services? Is my only choice to compile a new dev version of Go? Are there any newer binaries available?
salmodan: there is no published version of the code that does the weird renegotiation dance that Azure needs. I wrote a patch for some folks who needed it, but it didn't make Go 1.3. I do think, at this point, that supporting Azure is sufficiently compelling for 1.4 however.
Labels changed: added release-go1.4, removed priority-triage, release-none.
luke@webconnex.com: what patch do you think was reviewed before the freeze? I may have missed one. In general, sites that do this are mistaken and the solution is a hack which is why I've resisted doing it. This form of authentication is also broken by triple-handshake attacks[1] and the fix for that hasn't gone through the IETF yet. It needs careful thought in order to minimise the amount of disruption to the code while supporting these needs. [1] https://secure-resumption.com/
what #7 mentioned is a commit that is in 1.4. the reason this issue is not closed by that commit is that we still need client support, but the secure solution hasn't been made into official RFC yet. To summarize, there is no unreviewed pending patch for this issue, and before the RFC come out, we can't do anything about the client side of the issue. (agl explained why he didn't want to implement a workaround in #12)
https://github.com/MSOpenTech/azure-sdk-for-go includes a forked copy of net/http because they needed to be able to talk to Azure servers. Is it possible to support only the limited behavior of the Azure services without getting into the entire TLS renegotiation mess?
@rsc Thanks for bringing this up. We are still looking for a clean solution to handle client-side custom TLS renegotiation in the Azure Go SDK and get rid of the crypto/tls
fork we have in our repo.
Too late for 1.5?
I ran into this again today with a new service we are using. It would be great if this could get resolved somehow. We're using go-curl now as rogpeppe suggested, but not having the cgo dependency would be super nice and ease cross compilation of our project.
This is still tagged with Milestone Go 1.5, but I don't know @agl's latest thoughts on this. Adam?
Would it be less invasive if it was made an option like InsecureSkipVerify: true
? AllowRenegotiation: true
?
@ottob that surely sounds less invasive and testable. +1 for InsecureSkipVerify. How do others feel? @agl
Punting to 1.6 because it obviously didn't make 1.5.
In BoringSSL we're settling on removing all renegotiation support except for server-initiated (when explicitly allowed on the client connection) and disallowing concurrent application data flow with the handshake.
That does seem plausible for Go to do too, although it's quite a lot of complexity for a weird, Microsoft corner case. None the less, it'll likely happen.
+1 for AllowRenegotiation.
Like probably everyone else who wants the feature here, talking to Microsoft stuff (in addition to Azure, you need this for using certificate auth to WinRM) is the use case. And yeah, it's just a weird Microsoft corner case, but it is also a weird Microsoft corner case our customers are demanding. Like it or not, SCVMM and Azure (and, generally, WinRM) are part of the landscape, and I'm sure I'm not the only person whose software has to interoperate with them.
It would be really good to have this in 1.6 to support Azure. @agl do you think you'll be able to tackle it in this cycle? I would be willing to take it on, but I have next to no knowledge in this area.
+1 for renegotiation support, we are also having trouble with postgres and redshift
I found this today: https://boringssl.googlesource.com/boringssl/+/2ae77d2784b4080afa65575fb101de76fc5cef52%5E!/
Is there any chance this might make it into 1.6?
I think it's @agl's choice whether he trusts that code enough to put it in the standard library at this point.
I'm also interested in TLS renegotiation. I think Vegeta's -insecure flag (Ignore invalid server TLS certificates) is dependant upon it.
Too late for Go 1.6, sorry.
Hello from BBC. We're also very eager to see this make its way into 1.7 as all of our platforms are behind self-signed client cert auth and so renegotiation issues have cropped up a few times for us.
Is there a fork with this fix in as I also work for the BBC and this is holding me back?
@aidylewis yes there is an old fork here that has this feature. https://github.com/Azure/azure-sdk-for-go/tree/master/core/tls
Any chance of this happening in 1.7?
It would be very nice to add the renegotiation feature. It would help to use the stdlib in development for https winrm support protocol package insted of some forks.
https://go-review.googlesource.com/#/c/22475/ may address this bug, but the primary use case is HTTPS servers which do the Microsoft trick of renegotiating a connection to add client certificates and I don't have any.
Can any interested party here either point me at such a server (with or without a test certificate to authenticate with) or test that patch themselves?
CL https://golang.org/cl/22475 mentions this issue.
@agl reaching out to you via email to provide an endpoint and certs.
@ahmetalpbalkan thank you!
@agl thanks for confirming the fix and thanks for the patch.
So this is resolved?
There is a CL out that I expect to be in Go 1.7. This bug will be closed when the CL is committed to Git, but you'll have to wait for Go 1.7 to use it (unless you run from the Git master branch, which can be unstable at times and is not recommended for production code).
The patch works fine for me. Huge thanks to @agl!
Thanks for clarifying @rsc, and thanks @agl again for the patch.
Has anyone tested this with the Go 1.7 RC?
@aidylewis, @ottob above said he had tested this.
Also verified this with go1.7rc6
in azure-sdk-for-go
.
Just to be explicit to future readers: this feature has been merged into master, and you can use it by setting the Renegotiation
field in your *tls.Config
to tls.RenegotiateFreelyAsClient
:
config := &tls.Config{
Renegotiation: tls.RenegotiateFreelyAsClient,
}
Thanks @elimisteve :-)