Leverage caddy-l4

[Lingxi-Li]

I noticed caddy-l4 which is under active development. It seems that one can achieve the same functionality with caddy-l4 than with forwardproxy. Maybe, should focus on caddy-l4 development and simply showcase here a Caddyfile that implements forward proxy using caddy-l4. @mholt , your time is too valuable to be spent on less value targets.

[gaby]

I'm pushish all my changes for #74 today. There is still an issue with http/3 headers though. Up to @mholt to decide if using that one makes more sense. My understanding is that forwardproxy is doing more than just simple tcp/udp proxies

[mholt]

Yeah, thanks for the suggestion!

I'm not sure how that would look. Caddy-L4 contains a reverse proxy, but not a forward proxy. And that proxy is application-agnostic. This one is HTTP-specific. If it was caddy-l4, you'd have to use a separate config file (JSON currently, as there's no official Caddyfile support), whereas with this forwardproxy you can use the Caddyfile.

Do you have anything specific in mind as to how we could achieve the same functionality with caddy-l4?

[klzgrad]

Can't do forward proxying with caddy-l4 in a single caddy binary (must run a separate back end for forward proxying).

Not clear how to do header based probe resistance in caddy-l4.

[Lingxi-Li]

I kind of confused the concept of load balancer and forward proxy. The "forwardproxy" here serves both roles. Compared to this monolithic design of bundling together load balancer and forward proxy, a modularized design is more flexible by allowing users to customize by piecing together different modules.

E.g., @klzgrad developed a custom forward proxy "naive". Since the forward proxy is built into "forwardproxy" and non-separable , a fork has to be made to support this custom logic. This is not good, requiring logistical overhead to keep base and fork in sync. This is despite the fact that there is already a standalone "naive" forward proxy server there. It just cannot plug in.

I see caddy-l4 promising to implement a load balancer. It's like 1) terminating TLS, 2) matching authorization header, and 3) routing appropriately to either a forward proxy or file server. User can then plug in whatever forward proxy he/she sees fit. No more fork and code change is necessary.

So, to be precise, I don't intend to see caddy-l4 play the role of the holistic "forwardproxy", but only its load balancer part. And I don't see the holistic approach adopted by "forwardproxy" is a good design.

@mholt , config format is minor. caddy-l4 will support Caddyfile sooner or later, right? :grin:

[mholt]

@klzgrad Hey, I am a fan of your work! :100:

@Lingxi-Li Ok, I see what you mean -- so you're talking about having a forwardproxy module implemented to work with Project Conncept (caddy-l4) so that the pieces that make this forwardproxy work are more composable and flexible for advanced users, right?

I like that idea. Would that ease your maintenance burden, @klzgrad ?

config format is minor. caddy-l4 will support Caddyfile sooner or later, right? grin

Ha, um, I hope so. :woozy_face:

[klzgrad]

The reason forwardproxy alone is not enough is because it lacks a packet length padding layer that is needed to mitigate TLS-in-TLS handshake signatures. It has the upstream directive that can pass traffic to a backend process, which was the previous solution where naive.exe ran along with vanilla Caddy server and the forwardproxy plugin to provide this padding layer. The padding logic is quite simple, and running a second executable is a hassle for user deployment, so I made some small addition to let forwardproxy handle the padding directly. But this padding layer is experimental and not quite appropriate for merging into forwardproxy for general use, so it remains a fork.

I don't have any maintenance burden in keeping a forwardproxy fork for this padding layer. It hasn't changed for years. The status quo works, and I'm not seeing great benefit in migrating to caddy-l4 for this use case.

[Lingxi-Li]

@klzgrad Thanks for the detailed clarification. I mis-read the upstream directive of forwardproxy.

Close this thread as no real motivation to move to caddy-l4 for now. That being said, it still makes sense to minimize feature overlap and save efforts.