proposal: support TLS proxy between clients and the kes server

[aead]

What is the problem you want to solve?

Currently it's not possible to put a TLS proxy - e.g. a nginx as load balancer - between the kes server and its clients. The reason is that the kes server uses mTLS for client authentication and determines the policy that should be applied based on the X.509 certificate of the client.

Now, when putting a TLS proxy in between kes and its clients, kes cannot "see" behind the proxy. So, for KES it looks like each request is made by the proxy. All information about the actual client is not accessible to KES.

How do you want to solve it?

One possible solution would be to instruct the TLS reverse proxy to forward the client certificate as an HTTP header. So the TLS proxy would do the client-mTLS termination (now the TLS proxy is responsible to verify whether the client certificate is authentic - i.e. signed by a trusted CA), and then, establishes another TLS connection to kes. As part of the request the TLS proxy sends a "special HTTP header" containing the client certificate. So, the KES server verifies that the connection attempt actually has been made by the TLS proxy, then extracts the certificate of the client from the "special header" and applies the policy roles to this certificate.

This would require some additional TLS configuration. For example:

[tls]
key  = "./server.key" # Path to the TLS private key
cert = "./server.cert"  # Path to the TLS certificate

[tls.proxy]
identities = [  "ad291559b8668d9faecd593a75e9e52682a5017f7a147ce97e4da16a144021df",
                "abaa92259f360b6212f911d0fd9bd333a22d013f4387aba85e1cf1a86096ba6d"
             ]

The TLS proxy configuration contains X.509 identities of all TLS proxies that are allowed to verify clients and can forward their certificate to KES.

Additional context

1. Are there alternative solutions?
   Not really, however they may be many variations of the solution above. For example, should there be identities or just a separate CA-chain for proxies a.s.o.

2. Would your solution cause a major breaking API change?
   No

3. Anything else that is important?

There are some things that needs decision. In particular,

• Should we use identities for proxies or use a separate intermediate CA that issues certificates only for kes TLS proxies.
• Should it be possible to add and remove proxy identities at runtime
• If not, how do we update kes when the identity of a proxy changes (e.g. K8S deploys one more with a different TLS private key / certificate). Restart kes?!

One critical aspect is that the reverse proxy can act as any identity - since it just can send arbitrary certificates. The kes server has no (direct) way to verify that there is actually a client with this identity making a request.
To mitigate a "malicious" reverse proxy we would need to require that the proxy forwards (parts) of the client handshake. This effectively means doing a TLS pseudo-handshake with the information forwarded by the client. However, I'm not sure whether this works at all (with the Go TLS implementation).

[aead]

/cc @Alevsk Is this something that may help solving deploying TLS on K8S.

[aead]

We may also need to make the forwarded header configurable. Traefik for example sets X-Forwarded-Ssl-Client-Cert See: traefik/traefik#3052 and traefik/traefik#3826

[aead]

Suggesting the following configuration:

[tls]
key  = "./server.key" # Path to the TLS private key
cert = "./server.cert"  # Path to the TLS certificate

# The TLS proxy configuration to allow a TLS proxy in between the client and the kes server.
[tls.proxy]
# Enable or disable TLS proxies. By default: false.  
enable: false
# The X.509 identities of all TLS proxies directly talking to the kes server.
identities = [  "ad291559b8668d9faecd593a75e9e52682a5017f7a147ce97e4da16a144021df",
                "abaa92259f360b6212f911d0fd9bd333a22d013f4387aba85e1cf1a86096ba6d"
             ]
# Path to custom CA certificate resp. directory containing custom CA certificate(s).
# A proxy must present a certificate issued by one of these CAs when establishing a
# connection to the server. If not set, the default system root certificates are used.  
ca = "./proxy-ca.cert" 

[aead]

Okay so based on traefik/traefik#3826 and the nginx config option:
proxy_set_header X-SSL-CERT $ssl_client_escaped_cert; the config change will be as following:

[tls]
key  = "./server.key" # Path to the TLS private key
cert = "./server.cert"  # Path to the TLS certificate

# The TLS proxy configuration to allow a TLS proxy in between the client and the kes server.
[tls.proxy]
# Enable or disable TLS proxies. By default: false.  
enable: false

# The X.509 identities of all TLS proxies directly talking to the kes server.
identities = [  "ad291559b8668d9faecd593a75e9e52682a5017f7a147ce97e4da16a144021df",
                "abaa92259f360b6212f911d0fd9bd333a22d013f4387aba85e1cf1a86096ba6d"
             ]

# Path to custom CA certificate resp. directory containing custom CA certificate(s).
# A proxy must present a certificate issued by one of these CAs when establishing a
# connection to the server. If not set, the default system root certificates are used.  
ca = "./proxy-ca.cert" 

# HTTP header keys used by the TLS proxy to forward information about the client,
# like the client TLS certificate, to the kes server.
[tls.proxy.header]
cert = "X-Forwarded-Ssl-Client-Cert" # The client certificate forwarded by the proxy.