Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Neko without websockets? #457

Open
CodeSource1234 opened this issue Dec 12, 2024 · 8 comments
Open

Neko without websockets? #457

CodeSource1234 opened this issue Dec 12, 2024 · 8 comments

Comments

@CodeSource1234
Copy link

CodeSource1234 commented Dec 12, 2024

Hi:

Thank you for making Neko. It's an awesome piece of software.

I currently have Neko built and installed successfully. My test behind a network that allows websockets was successful.

The network I would like to use Neko under has a strict firewall that rejects Websockets (prevents the HTTP upgrade).

Is it possible to configure Neko for use without websockets?

I was hoping this was possible since WebRTC is allowed under this network.

If this is not possible with Neko, do you recommend any other similar software (remote desktop) that will work without websockets? Currently, I can only get Apache Guacamole to work without websockets but it's unbearably slow.

Thanks.

@m1k1o
Copy link
Owner

m1k1o commented Dec 12, 2024

Hi. It could be definitely changed to work like that, but that change would not be trivial.

Would SSE (server sent events) be allowed? That could simply a lot.

@CodeSource1234
Copy link
Author

Thanks for the response.

I tried some SSE sites on the network and SSE seems to work.

From what I can tell, most other web protocols have worked. Popular media websites work (youtube, etc). Websockets seem specifically targeted.

I wouldn't ask you to make changes to your software just for this since I feel it's not common to have all websockets blocked.

I was hoping maybe there is a way to use Neko currently without websockets.

Thanks!

@m1k1o
Copy link
Owner

m1k1o commented Dec 12, 2024

Neko uses gorilla/websocket so maybe there exists a variant of this library that would not use webosckets but instead a combination of HTTP Requests + SSE. It could be then added by go replace as 1:1 replacement for the dependency.

On the javascript part, there could exist a polyfill that would again implement the javascripts WebSocket API but replace it with custom code that could communicate with the modified server counterpart.

Not sure if something like this exists, but if not it would be probably a very good way to solve this problem for any application, not just neko.

@CodeSource1234
Copy link
Author

I wish I was more knowledge on web development or I would offer my help. I'll keep an eye on Neko and see if something like this pops up.

Thanks!

@Technetium1
Copy link

SSE doesn't have a way to replace 1:1 as mentioned. Especially with it only being server to client, so I don't think such a library variant with those modifications would exist. I also see potential for pain when straying from widely accepted solutions.

@CodeSource1234 This doesn't make much sense:

I was hoping this was possible since WebRTC is allowed under this network.

The signaling for WebRTC is almost ALWAYS over WebSockets... Open your developer tools, go to the network tab, reload page, and see if you can find the upgrade request. It should be a GET request with status 101 for an upgrade.

The easy fix would be to use a VPN. You can run your own with something like https://shadowsocks.org or https://www.v2ray.com/en and generally bypass most firewalls. Mullvad can be a legitimate paid option. Pay attention to setting the advanced options to enable any necessary bypasses like connection port or Shadowsocks.

@m1k1o
Copy link
Owner

m1k1o commented Dec 13, 2024

SSE doesn't have a way to replace 1:1 as mentioned. Especially with it only being server to client, so I don't think such a library variant with those modifications would exist. I also see potential for pain when straying from widely accepted solutions.

Thats why I mentioned HTTP Requests + SSE.

  • Traditional HTTP request for Client to Server communication.
  • SSE for Server to Client communication.

Socket.io can do that already and work even in networks where no WebSockets are available. Maybe there exists alteady some Go alternative.

The idea of having alternative to websockets is already outlined in #371 but currently there was no reason to implement it as in almost every network where WebRTC is enabled also Websockets are.

@Technetium1
Copy link

I notice you didn't add HTTP/3, maybe notice https://github.com/quic-go/quic-go? Since you are doing a major rewrite, it may be interesting to consider alongside WHIP/WHEP.

Socket.io can do that already and work even in networks where no WebSockets are available. Maybe there exists alteady some Go alternative.

Socket.io is an old, unique beast. It existed between different eras of real-time communication, which is partly the reason for its popularity and active maintenance. Asking for similar in Go is intensely unlikely. I don't see a world where you can get such functionality without doing a lot of work yourself. I look forward to anyone's ideas and any links.

Thanks for mentioning the related issue, I've subscribed to notifications.

@CodeSource1234
Copy link
Author

CodeSource1234 commented Dec 15, 2024

The signaling for WebRTC is almost ALWAYS over WebSockets... Open your developer tools, go to the network tab, reload page, and see if you can find the upgrade request. It should be a GET request with status 101 for an upgrade.

On the restricted network that I'm dealing with, whenever an HTTP upgrade is attempted for a websocket, I see this response coming through in the Firefox debugger (this is with HTTPS/TLS):

NS_ERROR_WEBSOCKET_CONNECTION_REFUSED

Also, I've tried using curl on a linux machine under this network with no local firewall to simulate a websocket request (without HTTPS/TLS) and received a kickback page saying "websockets are blocked" from the back-end/remote firewall, which is McAfee Web Gateway (Trellix).

I've read that upgrade header requests should be hidden in the TLS but, if that is the case, I don't understand how these upgrade requests are blocked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants