Alternate approach to proxying

[ameba23]

Alternative proposal based on conversation with @0x416e746f6e:

• Attestation generation and verification should be done once per TLS certificate, not once per session (certificate binding but no session binding).
• Have an intermediary CA-endorsed entity which signs certificates with the attestation evidence included as a certificate extension.
• Already validated remote certificates (together with attestation evidence) are cached by the proxy client or proxy server.

Protocol:

1. When a TCP connection from the source client to the proxy client is made, the proxy client connects to the proxy server, and does a TLS handshake, optionally with client authentication (unlike the current protocol, the proxy client does not eagerly connect and keep the session open).
2. The proxy-client checks if it has already validated the attestation evidence from the remote certificate (included in the extension), by checking its cache. If not, it validates the evidence in the certificate extension and adds it to the cache.
3. If client authentication is enabled, the proxy server does the same with the client certificate and evidence.
4. The proxy client begins forwarding traffic from the source client connection to the proxy server.
5. The proxy server makes a TCP connection to the target service and begins forwarding traffic from the proxy client.

Advantages:

• Protocol agnostic (see Consider making raw TLS over TCP based proxy #54)
• Attestation generation and verification only once per certificate (saves time).

Disadvantages:

• No session binding / freshness guarantee (maybe not an issue)
• TLS handshake between proxy client and proxy server is performed once per connection from the source client. Current design keeps the connection open.

I think whether this approach makes sense depends on the use-case. The current design is based on the needs of buildernet node to builder hub, where frequent requests are made to get details of active peers (meaning it makes sense to keep the connection open and avoid additional TCP and TLS handshakes.

It could be worth considering to support both approaches, either through command line options or by having a second crate using some of the functionality from this one.

@0x416e746f6e please let me know if this description fits what you were imagining.

[0x416e746f6e]

please let me know if this description fits what you were imagining

yes, the idea is captured very accurately. the only missing parts are:

• whether validated certs are cached or not can be made optional (e.g. with a CLI flag) => this would allow the user to have full control the over the level of security guarantees, and allow them to use the level appropriate to their particular use-case.
• always keeping a single established attested tls connection open could be disadvantageous in some scenarios (in other words, it's not necessary a pro). for example:
  • under high RPS of http requests, all the requests would have to squeeze themselves into a single channel b/w client and server sides of the proxies even when the querying workload would establish multiple tcp connections to its side of the proxy client.
  • and if we try to mitigate the above by detecting the exhausted bandwidth of existing single conn and adding extra one(s), then we might introduce undesired parallelism for the use-cases that expect strictly single tcp connection b/w client and the server (i.e. there are cases when the http requests should be delivered strictly in the same sequence as the client app issued them, so if there is suddenly 2+ tunnels then that could cause race conditions that are very hard to debug/triage).
• opening/closing attested tls tunnels per opened/closed client connections would make attested-tls-proxy to act completely transparently without altering any properties of the proxied connection (except for the latency added by the attestation validation + latency of double-proxying). which might be very desirable sometimes.

[0x416e746f6e]

another consideration is: perhaps we could decouple the attested tls tunnel setup from actual proxying.

reason is: in case of HTTP proxying, some of the servers really expect to see x-forwarded-for header in case of proxied connections, and would reject the ones that have host: localhost b/c it's not in the allow-listed CORS. therefore the HTTP proxy could be a wrapper around attested tls tunnel that adds correct headers handling/injection into already provided connectivity.