Most Teleport-specific ALPN protocols don't confirm the selected ALPN protocol

[espadolini]

Expected behavior:

Connecting to the Teleport web listener with a Teleport-specific ALPN (say, teleport-proxy-ssh-grpc) should result in the TLS ServerHello containing the negotiated protocol, as that will allow clients to not rely on potentially outdated autodetected state with regards to the presence of TLS terminators between the client and the control plane (that would trigger the HTTP Upgrade-based connection tunneling), and it will allow both parties to actually negotiate protocols among multiple ones that might be supported instead of just assuming that the chosen protocol is mutually supported.

Current behavior:

From a cursory look, the only protocol that works correctly is teleport-reversetunnel, with other protocols resulting in no protocol selection (which is hard to distinguish from a middlebox doing TLS interception with no idea of what to do with the Teleport-specific protocols); dishonorable mention to the magic teleport-auth@<hex cluster name> "tag" which only works on first position and completely changes the meaning of the ALPN selection, with the auth server actually requiring one of h2 or http/1.1 to be selected.

Bug details:

• Teleport version: likely since the introduction of ALPN for protocol selection
• Recreation steps: openssl s_client -connect <proxyhostname>:443 -alpn teleport-proxy-ssh