Skip to content

crypto/tls: Buffering of handshake messages causing issues with HAProxy #19575

Description

@dragorosson

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 reports Linux {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:

* Rebuilt URL to: https://172.24.4.2:10443/
* Hostname was NOT found in DNS cache
*   Trying 172.24.4.2...
* Connected to 172.24.4.2 (172.24.4.2) port 10443 (#0)
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1): # it sits here forever

Only this specific combination exhibits the problem. That is:

  • making a request to the floating IP from the outside...
  • when the FIP is attached to the LB node...
  • with an apiserver built on 2a8c81f or newer listening on the other side

Things that, interestingly, do work (all done separately):

  • Swapping out the apiserver for openssl s_server allows full two-way communication
  • Using an apiserver built on Go before 2a8c81f
  • Making a request to etcd (non-TLS) on the same node (different port, but through the same LB, FIP, etc)
  • Sending requests to the LB's floating IP from the api node
  • Sending requests to the private IP of the api node from the LB node (bypassing the LB and the FIP)
  • Attaching the floating IP directly to the api node (bypassing the LB) and making requests to it (works from the outside too in this case)

I 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)

global
    daemon
    user nobody
    group nogroup
    log /dev/log local0
    log /dev/log local1 notice
    stats socket /var/lib/octavia/7619d633-7114-4077-80fe-df8a7c9ec343.sock mode 0666 level user

defaults
    log global
    retries 3
    option redispatch
    timeout connect 5000
    timeout client 50000
    timeout server 50000

frontend 7619d633-7114-4077-80fe-df8a7c9ec343
    option tcplog
    bind 10.0.0.8:10443
    mode tcp
    default_backend cbfdf089-ca1c-4274-936a-592d4409b30a

backend cbfdf089-ca1c-4274-936a-592d4409b30a
    mode tcp
    balance roundrobin
    timeout check 5
    server 2d0e02a2-f638-4585-8868-36eb491fbcfb 10.0.0.15:10443 weight 1 check inter 5s fall 3 rise 5

Some HAProxy logs (more at https://gist.github.com/dragorosson/9843b863e77b316ea4128f0ee1661c73):

Mar 15 15:45:16 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38562 [15/Mar/2017:15:44:26.580] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0
Mar 15 15:46:07 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38652 [15/Mar/2017:15:45:17.584] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:46:58 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38744 [15/Mar/2017:15:46:08.589] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0
Mar 15 15:47:49 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38838 [15/Mar/2017:15:46:59.594] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:48:40 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:38926 [15/Mar/2017:15:47:50.598] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:49:31 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:39018 [15/Mar/2017:15:48:41.602] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50002 215 sD 0/0/0/0/0 0/0
Mar 15 15:50:22 amphora-29e9ad63-0bca-47d8-8b76-1737a4baefb3 haproxy[1866]: 172.24.4.12:39112 [15/Mar/2017:15:49:32.606] 5586e340-7482-4e7f-a8ec-b3ab5719b08e 61fc85f1-f790-444e-b74b-ee31b2a313d7/bd114259-0a52-443b-96f0-52e5ebdd8204 0/0/50003 215 sD 0/0/0/0/0 0/0

Metadata

Metadata

Assignees

No one assigned

    Labels

    FrozenDueToAgeNeedsInvestigationSomeone must examine and confirm this is a valid issue and not a duplicate of an existing one.WaitingForInfoIssue is not actionable because of missing required information, which needs to be provided.help wanted

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions