search

gravitational / teleport

The easiest, and most secure way to access and protect all of your infrastructure.
https://goteleport.com
GNU Affero General Public License v3.0
17.32k stars 1.74k forks source link

Reverse tunnel connections with TLS routing are inefficient because of connection upgrade tests #44872

Open espadolini opened 1 month ago

espadolini commented 1 month ago

Reverse tunnel connections (when TLS routing is enabled, which should be most of the time in "modern" Teleport) use the same ALPN (teleport-reversetunnel) as used by the "ALPN connection upgrade" mechanism, but the API client currently uses a completely separate TLS connection that completes a full TLS handshake just to discover whether or not the current network routes connections directly to the Teleport Proxy service or to a L7 reverse proxy.

In addition to being potentially wrong (two consecutive connections might alternate between reaching the Teleport Proxy and a middlebox), we could instead use just one connection and, after a TLS handshake, figure out whether or not we've reached a Teleport Proxy service directly or a middlebox - proceeding then with the HTTP connection upgrade if necessary. This would effectively halve the TLS handshakes and the incoming connections on the control plane proxies that stem from the Teleport agents' reverse tunnel connections and, until #37608 is addressed, connections to the Auth Service from all agents.

espadolini commented 1 month ago

Address discovery also plays a part in this: before the API client connects to a proxy, it issues a GET on /webapi/find, which means that a TLS connection is opened and we could potentially use it to detect whether or not we've reached the Proxy Service directly or not - and if not, we could just then continue using the connection for the connection upgrade path.