Pingora as Forward Proxy

[johnncray]

What is the problem your feature solves, or the need it fulfills?

Hello pingorans,
I am researching Rust frameworks to implement a high-performance, highly-programmable forward proxy. I like pingora, but it seems to be designed to be used as a reverse proxy. I'm currently trying to see if I can use it as a forward proxy without changes to its core functionality. It seems like I might be able to do that but before I go too deep, I wanted to hear the opinion of the authors/maintainers with regards to this use-case. Do you think I will be fighting a losing battle going down this path and trying to twist the arm of pingora too much to shoehorn this use-case, or do you think that the use-cases are close-enough that I should be able to use pingora and its core functionality to build a forward proxy?

Describe the solution you'd like

Ideally, I'd love be able to use pingora as a forward proxy.

Describe alternatives you've considered

1. Still experimenting with implementing changes to the request headers to rewrite the proxy protocol to direct HTTP requests
2. There's bytedance/g3 which seems to be designed to do just that, but I haven't tried it yet

[eaufavor]

The fundamental difference between forward proxy and reverse proxy is who the proxy works on behalf of, the client or the server. So you can make a forward proxy with Pingora.

On the other hand, Pingora doesn't implement typical protocols such as http CONNECT, PROXY protocol or SOCKS. So it does not work out of box with clients that expects one of these protocols.

[johnncray]

Thanks for your answer.

With regards to the http CONNECT support, I can implement this part but what I am less clear on is if Pingora allows for the developer to switch/upgrade from plain text to TLS in the middle of the same connection as well as return direct responses generated straight from the proxy or go to upstream proxying, again within the same connection. Let me explain.

What I need to do is a certificate bump, i.e. TLS interception/MITM with certificate generation. This means that:

1. Client connects to the proxy, issues a plain-text CONNECT request, Pingora returns directly (no proxying) a 200 OK
2. Client starts TLS handshake and Pingora now needs to meet this TLS handshake and terminate it locally with its own certificate so that it can do traffic inspection
3. After the TLS is established between the client and Pingora, then we open up the upstream connection to the target server (another TLS) and start copying the traffic between the two TLS sockets with potential for inspection/modification

Is this possible?

Thanks

[github-actions]

This question has been stale for a week. It will be closed in an additional day if not updated.

[github-actions]

This issue has been closed because it has been stalled with no activity.