TLS Bumping in Envoy Design Doc

2022.10.31

PoC: #23192
README and configurations are in tls_bumping subdir

2022.07.13
4 work items were worked out.

1. Certificate Provider framework
   Implement CertificateProvider mechanism #19308
   Implement Certificate Provider Framework (#19308) #19582
2. SNI-based cert selection in tls transport socket
   SNI-based cert selection in TLS transport socket #21739
   SNI-based cert selection during TLS handshake #22036
3. A new network filter - BumpingFilter
   Add a bumping filter for cert mimicking #22581
   WiP Add Bumping filter #22582
4. Certificate Provider instance - LocalMimicCertProvider
   WIP: Local cert provider #23063

2022.04.24 update

Mimicking certs only based on SNI is probably not enough, we require server real certificate and ensure to copy subject, subject alt name, extensions, knowing about the RSA key strength and many more. Original proposal was to set up client-first secure connection, to meet above requirements we need server-first secure connection.

Therefore, we expect the workflow like this:

1. downstream requires accessing some external websites like "google.com", the traffic is routed to Envoy
2. Envoy receive the CLIENT_HELLO but don't do handshake with downstream until step5
3. Envoy connects "google.com" (upstream) and get real server certificate
4. Envoy copies the subject, subject alt name, extensions, etc from real server certificate and generates mimic certificate
5. Envoy does TLS handshake with downstream using mimic certificate
6. traffic is decrypted and go through Envoy network filters, especially HCM, there are many http filters and user can also expand http filter easily with WASM to plugin in many security functions.
7. traffic is encrypted and sent to upstream.

Original Proposal

Title: decrypting communications between internal and external services

Description:

When Envoy works as sidecar or egress gateway in service mesh, Istio takes responsibility of certification generation and pushing the configs to Envoy via xDS. But when it works like typical proxy, the internal services on the edge might access many different external websites such as Google or Bing etc, Envoy does't provide the ability to terminate this kind of TLS traffic.
For this scenario, we propose a method to let Envoy generate certs dynamically and do TLS handshake. Then if the client trusts the root ca that the certs signed from, it can access external services under the control of Envoy.

Changes (straw man)

1. introduce an API to enable this feature and configure ca crt and key for signing
2. get sni from tls inpector (we need sni to generate certs, just utilize tls inspector, probably no changes)
3. generate certs according to sni
4. set the certs to SSL object and then do handshake

Any comments are welcome.