Full HTTP Proxy protocol support for a "Home VPN"

[TheRook]

I need a full HTTP Proxy over a websocket and i noticed GT is pretty similar.

The use-case here for a full proxy is you are traveling and you want to be able to watch TV from home. Sure I can use WireGuard or something like WebMesh which is a zero-config way of setting up a VPN. But... what if i want to access this VPN with a websocket?

GT will only forward to a specific host, but the HTTP Proxy protocol lets the client specify any host so that they can browse the web without censorship or being tracked. And this could work with the current GT web tunnel.

There is also the wssocks project which is Socks5 over websockets - in golang, which might be useful here?

Thoughts?

[vyloy]

GT can do that by running a socks proxy server with GT client and using TCP relay configuration.

Example of GT client configuration file:

version: 1.0
services:
  # run a socks proxy server on local with port 1080 or any port you want and then update the value of local
  - local: tcp://127.0.0.1:1080
    # port to open on GT server
    remoteTCPPort: 11080
    # open a random port on GT server if port was used
    remoteTCPRandom: true
options:
  id: id-should-be-overwritten
  secret: secret-should-be-overwritten
  # GT server address
  # remote: tls://1.1.1.1:4443
  remote: tcp://1.1.1.1:80
  remoteConnections: 5
  logLevel: info

Now enjoy the socks proxy by using port 11080 on GT server.

Does this solution sound ok to you?

[TheRook]

That isn't a socks proxy at all. You hard coded the remote host. This is exactly the point of my ticket if gt supported socks5 or the HTTP Proxy protocol then it would be a lot more useful.

Are you interested in adding this feature?

On Wed, Sep 13, 2023, 8:17 PM Vyloy @.***> wrote:

GT can do that by running a socks proxy server with GT client and using TCP relay configuration.

Example of GT client configuration file:

version: 1.0services:

run a socks proxy server on local with port 1080

• local: tcp://127.0.0.1:1080

  port to open on GT server

  remoteTCPPort: 11080

  open a random port on GT server if port is using

  remoteTCPRandom: trueoptions: id: id-should-be-overwritten secret: secret-should-be-overwritten

  GT server address

  remote: tls://1.1.1.1:4443

  remote: tcp://1.1.1.1:80 remoteConnections: 5 logLevel: info

Now enjoy the socks proxy by using port 11080 on GT server.

Does this solution sound ok to you?

— Reply to this email directly, view it on GitHub https://github.com/ao-space/gt/issues/29#issuecomment-1718702158, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD7MN55ETRQBYJH57HLLX3X2JZLJANCNFSM6AAAAAA4WSOJPY . You are receiving this because you authored the thread.Message ID: @.***>

[vyloy]

Yes, you are right, GT isn't a socks proxy, it can only relay socks traffic through TCP relay currently.

Is this what you want as the following exactly:

browser with socks proxy on hotel network -> GT server -> GT client -> socks proxy server -> any website

(GT client and socks proxy server is running on a PC at home. )

your browser should be able to do what described as:

GT will only forward to a specific host, but the HTTP Proxy protocol lets the client specify any host so that they can browse the web without censorship or being tracked. And this could work with the current GT web tunnel.

[TheRook]

Close, actually I'm thinking something like: Browser+WebRTC->GT Server->Any website or even sockets with TCP for JS via WebRTC. This could be used by a client app to access private resources as a kind of VPC.

The use-case here is similar to running a home VPN. The benefit of using webrtc is that it is very difficult for the GFW to filter. WebRTC also uses mTLS, so that's nice.

wsscocks is basically it... also gosocks is MIT so adding a Pion WebRTC handler doesn't sound that difficult.

I am using a polyfill of fetch() that doesn't know its using a proxy. The use-case here is that you can then tunnel out of the GFW or other similar networks without having to install anything. Any native browser can use webrtc.

The browser would need to use https://github.com/digitalbazaar/forge to make TLS connections for HTTPS, which still needs to be implemented.

[vyloy]

iOS, Android, Browser Clients of ao.space is able to make HTTP API request like:

Browser+WebRTC->[GT Server*]->GT Client->Local website

But this part of code at client side is not opened source yet. Here is an example: https://github.com/ao-space/gt/blob/dev/example/dev/web/p2p.js

Maybe this can help:

The only missing part of code to make things work as close as you want is the front-end code running in the Browser:

Browser+WebRTC->[GT Server*]->GT Client->Proxy Server->Any website

*: GT Server is only needed to help establishing WebRTC P2P connection between Browser and GT Client.

[TheRook]

That is a a shame! What does it take to open source this client library? I think by keeping it closed source, it means that others will have to re-implement it and it won't be compatible with your ecosystem.

But this part of code at client side is not opened source yet. Here is an example: https://github.com/ao-space/gt/blob/dev/example/dev/web/p2p.js

[vyloy]

Thank you very much for your feedback. Your suggestions are highly appreciated and we will definitely consider them.

Currently, AO.space has two versions: the Open Source version and the Trial version. We are constantly working to improve the stability and functionality of both versions. As features within the Trial version become more robust, we definitely plan to incorporate them into the Open Source version.

AO.space is a relatively new project, and we released our Open Source version only two months ago, which included the core platform, server, and client components. We also firmly believe that open source development is the best way to ensure the ownership, privacy and security of personal data. Therefore, we will continue to contribute additional code and features in the future, and we hope that the AO.space community will grow and mature with time.

Please stay tuned to our project, AO.space, so you can keep up with any updates or progress we make on this front. Thank you very much for your interest and support!

[TheRook]

Thank you for your thoughtful reply. May I suggest a commercial license like the one mongodb uses which is based on the CDDL? In short, this allows your company to maintain full commercialization and you retain the ability to be the only commerical cloud provider - but you can open source your great tech without fear of someone like me becoming competition instead of a client or even a community contributor.

Food for thought.

On Mon, Oct 9, 2023, 9:10 PM Vyloy @.***> wrote:

Thank you very much for your feedback. Your suggestions are highly appreciated and we will definitely consider them.

Currently, AO.space has two versions: the Open Source version and the Trial version. We are constantly working to improve the stability and functionality of both versions. As features within the Trial version become more robust, we definitely plan to incorporate them into the Open Source version.

AO.space is a relatively new project, and we released our Open Source version only two months ago, which included the core platform, server, and client components. We also firmly believe that open source development is the best way to ensure the ownership, privacy and security of personal data. Therefore, we will continue to contribute additional code and features in the future, and we hope that the AO.space community will grow and mature with time.

Please stay tuned to our project, AO.space, so you can keep up with any updates or progress we make on this front. Thank you very much for your interest and support!

— Reply to this email directly, view it on GitHub https://github.com/ao-space/gt/issues/29#issuecomment-1754322299, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD7MN7Q2E2A6H7BELHK5D3X6TDB5AVCNFSM6AAAAAA4WSOJP2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONJUGMZDEMRZHE . You are receiving this because you authored the thread.Message ID: @.***>

[vyloy]

Thank you for bringing it to our attention. We will definitely keep this in mind for future reference. However, at this time, we do not have plans to change the Apache License 2.0 for our projects. If we decide to make any changes in the future, we will consider it.

[TheRook]

Ok, then we will be the ones to release the feature: https://github.com/campfireprotocol