-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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: Buffering of handshake messages causing issues with HAProxy #19575
Comments
@dragorosson, see https://play.golang.org/p/3USaOszeMu for a basic TLS echo server. You can then |
@bradfitz Thanks. Turns out I'm now working on a fully-automated script to reproduce the problem. |
I've finished the script (OpenStack heat orchestration template) to reproduce the bug. It creates a server, installs devstack, installs docker, builds golang containers with the good and bad SHA, compiles the simple TLS server on both of them, and then creates a heat stack (within devstack) that includes an HAProxy LB and a server for the TLS server to go on. In all, it takes about an hour to complete. Using a flavor with more RAM should make it go faster, or even a bare metal server. If you do try a bare metal server, at least on the Rackspace cloud, you'll need to uncomment the NOTE: This template was developed using the Rackspace public cloud. With small modifications, it should work on other OpenStack clouds by changing only the Here are the manual steps:
source /opt/stack/devstack/openrc admin admin
Requests to the LB FIP with TLS server with the good SHA running should work. |
|
@bradfitz It's ready. |
@dragorosson, that's a repro I guess, but it's far from a minimal repro. I don't imagine @agl or I with our limited time will have an hour+ just to do that install. Is there a lighter weight repro? It seems like reproducing it is a good first step, but can you narrow it down now? Or at least get it down to a Dockerfile we can pull and run, without using OpenStack or Rackspace public cloud? |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
For more context, see the original Kubernetes bug report: kubernetes/kubernetes#40850
What version of Go are you using (
go version
)?2a8c81f (1.7 minus approximately 250 commits)
What operating system and processor architecture are you using (
go env
)?The kubernetes apiserver is running in a container.
uname -a
in the container reportsLinux {hostname} 4.9.7-101.fc24.x86_64 #1 SMP Thu Feb 2 23:32:31 UTC 2017 x86_64 GNU/Linux
What did you do? / What did you expect to see? / What did you see instead?
The setup requires a bit of explanation. I'm running a Kubernetes cluster with TLS enabled with an HAProxy LB in front of it on a separate node with a floating IP attached to it.
When trying to contact the kube-apiserver using
curl -vv -k https://{floating IP}:{k8s api port}
, it hangs at the client hello:Only this specific combination exhibits the problem. That is:
Things that, interestingly, do work (all done separately):
openssl s_server
allows full two-way communicationI am hoping that by submitting this report here, I can gain some additional insight into what the problem could be, especially because I have pinned 2a8c81f as the breaking commit.
P.S. If anyone has or could whip up a simple Go program that only listens on a port and establishes a TLS connection (two versions; at 2a8c81f and the commit before it), I could fully eliminate kubernetes from the equation. I'll try to work on it myself, but I haven't written a line of Go in my life. It would be super helpful!
HAProxy config:
(HA-Proxy version 1.5.14 2015/07/02)
Some HAProxy logs (more at https://gist.github.com/dragorosson/9843b863e77b316ea4128f0ee1661c73):
The text was updated successfully, but these errors were encountered: