-
Notifications
You must be signed in to change notification settings - Fork 18k
crypto/tls: does not support renegotiation #5742
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
Comments
Owner changed to @agl. Status changed to Accepted. |
> 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? |
This issue was updated by revision 779ef7b. |
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. |
[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/ |
[email protected]: "I wrote a patch for some folks who needed it" Can you please give a link to this patch? |
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? |
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! |
Has anyone tested this with the Go 1.7 RC? |
@aidylewis, @ottob above said he had tested this. |
Also verified this with |
Just to be explicit to future readers: this feature has been merged into master, and you can use it by setting the
|
Thanks @elimisteve :-) |
@elimisteve Cheers mate ! |
@Integralist Does that solve the Vegeta issue or is it a different app? |
@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 |
Issue golang/go#5742 resolved.
This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes golang#5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Russ Cox <[email protected]>
This change adds Config.Renegotiation which controls whether a TLS client will accept renegotiation requests from a server. This is used, for example, by some web servers that wish to “add” a client certificate to an HTTPS connection. This is disabled by default because it significantly complicates the state machine. Originally, handshakeMutex was taken before locking either Conn.in or Conn.out. However, if renegotiation is permitted then a handshake may be triggered during a Read() call. If Conn.in were unlocked before taking handshakeMutex then a concurrent Read() call could see an intermediate state and trigger an error. Thus handshakeMutex is now locked after Conn.in and the handshake functions assume that Conn.in is locked for the duration of the handshake. Additionally, handshakeMutex used to protect Conn.out also. With the possibility of renegotiation that's no longer viable and so writeRecordLocked has been split off. Fixes golang#5742. Change-Id: I935914db1f185d507ff39bba8274c148d756a1c8 Reviewed-on: https://go-review.googlesource.com/22475 Run-TryBot: Adam Langley <[email protected]> TryBot-Result: Gobot Gobot <[email protected]> Reviewed-by: Russ Cox <[email protected]>
The text was updated successfully, but these errors were encountered: