Question: Using Sozu as a forward proxy, egress gateway, egress proxy...

[marc-barry]

I happened upon your project when looking into the market for Rust-based proxy solutions. Ever since reading more about Oxy, Cloudflare's proxy solution (https://blog.cloudflare.com/introducing-oxy), I have thought that a Rust-based solution made a lot of sense. I use Envoy extensively today and drive its configuration via its xDS (over gPRC) interface. I really like the simply approach you have taken for a separation of the control plane and data plane.

I was looking into the viability of using Sozu as a forward proxy, egress gateway, egress proxy or any of the other names used to identify gateway's between clients and a service. There are some key needs to make this work and I wanted to check on the status of these efforts or support within this proxy.

• Does Sozu support both HTTP/1.1 and HTTP/2? This is table stakes as a large portion of the clients now use HTTP/2 and we have seen that is now accounts for the majority of the traffic.
• Is there any intention to add HTTP/3 support. It is UDP-based and its usage is climbing.
• In order to support proxy forwarding the proxy needs to be able to terminate TLS on the client side and establish TLS connections to destination. Does the proxy support TLS on both sides?
• Does the proxy support any sort of TLS inspection such that the proxy has access to the SNI of the client? In the case of transparent proxying this is generally used as the identifying domain used to dynamically proxy to a destination.
• In general, a flexible extension or middleware platform is needed in order to build custom functionality into the proxy. I found https://github.com/sozu-proxy/sozu/issues/685 and commented on the issue about a path that Envoy is going in regards to dynamic modules. Is there still plans and intension to support extending Sozu via extensions/middleware?

I have a few others questions but will first engage with these to check the viability of Sozu for some use cases I'm considering.

[Wonshtrum]

Hello and thank you for your interest in Sozu. First and foremost, we may have a misunderstanding, as Sozu is a reverse proxy and not a proxy. It is tailored to process ingress traffic, not egress, and thus might not be able to fulfill your needs. Nonetheless, to answer your questions:

1. currently, Sozu only supports HTTP/1.x, HTTP/2 is still in active development
2. we have the intention to add HTTP/3 support, but it is a really long-term goal and not a priority at the moment
3. since Sozu is intended for ingress, it only terminates the TLS connection and forwards the traffic in clear to the backends
4. in HTTPS Sozu actively searches for the SNI of the request. Without the SNI, Sozu is enabled to forward the appropriate certificate to terminate the TLS handshake
5. currently Sozu does not provide any extension capabilities. Wasm-based middleware support may come in a future version, but it is another very long-term goal

Does that answer your questions?

[marc-barry]

Does that answer your questions?

Yes, these answers are perfect.

First and foremost, we may have a misunderstanding, as Sozu is a reverse proxy and not a proxy. It is tailored to process ingress traffic, not egress, and thus might not be able to fulfill your needs.

Most reverse proxies can fulfil both directions but there are some subtle needs for which you answered my questions. I appreciate you taking the time.

[marc-barry]

I'm going to close my issue. At this time Sozu is missing a few small features preventing it from being used as forward proxy. It is optimized for reverse proxying.