Running fleet telemetry behind a trusted proxy

[bramp]

I would like to run this software behind a HTTP proxy that would terminate the mTLS connections. Because the proxy terminates the connections, the fleet-telemetry server would not see the client cert. However, many proxies can forward the client certificate, or common name to the backend via HTTP headers, e.g SSL_CLIENT_CERT/SSL_CLIENT_S_DN for Apache.

Would you accept a patch, that adds a config to enable reading the cert, from the HTTP headers, instead of from the SSL connection? If so, I'd be happy to contribute. Reading from headers would be purely optional, and need to be enabled to avoid the security risk of letting clients providing unauthenticated certs.

[patrickdemers6]

@sethterashima care to comment from a security perspective?

[sethterashima]

@bramp @patrickdemers6 no objection on my end, but I'd ask that: (1) the setting should be off by default and (2) if the setting is on and the server does receive a matching TLS client certificate, the connection should be (noisily) rejected with a call to action to disable the setting in the server configuration. The second requirement will prevent a user from inadvertently copy+pasting a configuration that makes them silently insecure. (Of course the second requirement is moot if it only accepts non-TLS connections).

[bramp]

I think those are both fair requirements.

To clarify #2, 'matching TLS client certificate', matching meanings a valid Tesla client cert? Should we instead just reject all client certs?

[sethterashima]

If the connection is over a trusted network and the telemetry server is only listening for HTTP (not HTTPS), then client certs are a moot point.

If the telemetry server is still using HTTPS (I'll defer to you and @patrickdemers6 on how likely this would be in contexts where there's a proxy), then rejecting all connections that use a client certificate is fine by me; if someone comes along who wants the proxy to authenticate with with the telemetry server using mTLS, then they're welcome to put in a feature request or PR.