Hello Yawning,
- There is an obfsproxy client instance running on c.example.com.
There is an obfsproxy server instance running on s.example.com, that feeds into an OpenVPN server instance running on v.example.com.
Multiple clients use c.example.com as the SOCKS proxy for the OpenVPN client, connect to s.example.com to get to the OpenVPN server running on v.example.com.
Correct with the exception that the machines won't be public.
My thoughts on the matter are:
- This should work. If it can be shown to be broken via a trivial application/test case (Eg: netcat), then it should be fixed (The trival test case requirement is because I don't want to debug OpenVPN again).
OK, what would be the best way to present this data?
- Oh god, c.example.com is going to be running a public SOCKS proxy. Granted people trying to use it to get to most destinations will have a connection that fails, but bad people can use it as a DDoS amplification host (The SOCKS dialog is much much shorter than any of the client requests that would be sent).
The SOCKS proxy will not be public far from that. The advantage on that is that I setup SOCKS proxy on the best location that for international traffic. On this specific country international traffic is very hard from most locations, just because the whole censorship infrastructure can't deal with all the traffic. Having the possibility to set it remotely would save work on deploying obfsproxy trough the OpenVPN clients and to set up yet another HTTP proxy in between the proxies.
- I don't know enough about the OpenVPN protocol/implementation to know if there are application specific quirks unique to OpenVPN that would prevent this configuration from working. That would be an OpenVPN problem, unless obfsproxy is altering the data it's relaying (Extremely unlikely).
How can I get proof of this ?
I am willing to dig into the code and provide a patch. But I could use some help with obfsproxy internals.
Thank you for your reply.
-- Regards, Alfredo Palhares