Go: crypto/tls: does not support renegotiation
We would like to use net/http to talk to Microsoft Azure services, but their servers force a TLS renegotiation, which crypto/tls does not currently support.
rogpeppe
All 53 comments
agl
on 20 Jun 2013
> 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?
rogpeppe
on 21 Jun 2013
gopherbot
on 9 Jan 2014
mikioh
on 10 Jan 2014
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?
gopherbot
on 8 Apr 2014
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._
agl
on 8 Apr 2014
Is there a reason why this wasn't included in 1.3 when it was reviewed well before the feature freeze? This occurs with FirstData's payment gateway API. Is there anything wrong with the patch itself? Is there a better way to address this issue?
lukescott
on 8 Apr 2014
[email protected]: 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/
agl
on 9 Apr 2014
"I wrote a patch for some folks who needed it". Can you please give a link to your patch?
gopherbot
on 25 Jul 2014
[email protected]: "I wrote a patch for some folks who needed it" Can you please give a link to this patch?
gopherbot
on 25 Jul 2014
rsc
on 15 Sep 2014
Will it be too late for 1.5 too? #7 patch has been sitting there for a year. Is there a problem with the patch?
gopherbot
on 20 Nov 2014
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)
minux
on 21 Nov 2014
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
on 9 Dec 2014
@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.
ahmetb
on 15 May 2015
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.
ottob
on 21 May 2015
This is still tagged with Milestone Go 1.5, but I don't know @agl's latest thoughts on this. Adam?
bradfitz
on 21 May 2015
Would it be less invasive if it was made an option like InsecureSkipVerify: true? AllowRenegotiation: true?
ottob
on 21 May 2015
@ottob that surely sounds less invasive and testable. +1 for InsecureSkipVerify. How do others feel? @agl
ahmetb
on 28 May 2015
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.
agl
on 30 May 2015
+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.
athornton
on 13 Aug 2015
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.
okdave
on 20 Aug 2015
+1 for renegotiation support, we are also having trouble with postgres and redshift
vincepri
on 27 Oct 2015
I found this today: https://boringssl.googlesource.com/boringssl/+/2ae77d2784b4080afa65575fb101de76fc5cef52%5E!/
Is there any chance this might make it into 1.6?
ottob
on 8 Nov 2015
I think it's @agl's choice whether he trusts that code enough to put it in the standard library at this point.
bradfitz
on 11 Nov 2015
I'm also interested in TLS renegotiation. I think Vegeta's -insecure flag (Ignore invalid server TLS certificates) is dependant upon it.
ghost
on 1 Dec 2015
Too late for Go 1.6, sorry.
rsc
on 3 Dec 2015
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.
Integralist
on 17 Feb 2016
Is there a fork with this fix in as I also work for the BBC and this is holding me back?
ghost
on 18 Feb 2016
@aidylewis yes there is an old fork here that has this feature. https://github.com/Azure/azure-sdk-for-go/tree/master/core/tls
ahmetb
on 18 Feb 2016
Any chance of this happening in 1.7?
ottob
on 3 Apr 2016
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.
hoenirvili
on 21 Apr 2016
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?
agl
on 26 Apr 2016
CL https://golang.org/cl/22475 mentions this issue.
gopherbot
on 27 Apr 2016
@agl reaching out to you via email to provide an endpoint and certs.
ahmetb
on 27 Apr 2016
@ahmetalpbalkan thank you!
agl
on 27 Apr 2016
@agl thanks for confirming the fix and thanks for the patch.
ahmetb
on 27 Apr 2016
So this is resolved?
hoenirvili
on 27 Apr 2016
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).
rsc
on 28 Apr 2016
The patch works fine for me. Huge thanks to @agl!
ottob
on 28 Apr 2016
Thanks for clarifying @rsc, and thanks @agl again for the patch.
hoenirvili
on 28 Apr 2016
Has anyone tested this with the Go 1.7 RC?
ghost
on 8 Jul 2016
@aidylewis, @ottob above said he had tested this.
bradfitz
on 8 Jul 2016
Also verified this with go1.7rc6 in azure-sdk-for-go.
ahmetb
on 9 Aug 2016
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,
}
elimisteve
on 20 Jan 2017
Thanks @elimisteve :-)
Integralist
on 20 Jan 2017
@elimisteve Cheers mate !
hoenirvili
on 20 Jan 2017
@Integralist Does that solve the Vegeta issue or is it a different app?
ghost
on 20 Jan 2017
@aidylewis Different app I think? Can't remember now. It was the team's own CLI app interacting with internal BBC service behind self-signed cert that was the issue iirc
Integralist
on 21 Jan 2017
Related issues
bradfitz
路
3Comments
michaelsafyan
路
3Comments
stub42
路
3Comments
natefinch
路
3Comments
jayhuang75
路
3Comments
Most helpful comment
Just to be explicit to future readers: this feature has been merged into master, and you can use it by setting the
Renegotiationfield in your*tls.Configtotls.RenegotiateFreelyAsClient: