WebSocket support

[clouedoc]

Requested feature

It's a crucially missing functionality (for us at least 😄)

Proposed solution

Warning: this chart looks terrible

The proposed solution is adding an API for WebSocket communications.

Who makes the code?

We are interested in either contributing code or funding the issue.
You can contact us privately (camille.eyries@gmail.com) to discuss this matter. If you give us directions on where/how to make the changes, we'll also be able to contribute directly.

[Danny-Dasilva]

Always happy to add new features and integrate stuff for use cases. I need some clarification on your use case. The diagram you wrote basically describes how CycleTLS currently operates unless I am misunderstanding something. Currently we are using ws as our socket server and spawn a golang client which listens to requests from our ws server. The golang side listens for incoming messages, processes the requests concurrently in a goroutine pool and returns them asynchronously.

The JS/Typescript side acts as the socket server and the golang side acts as a client waiting on the corresponding spawned port for requests.

Basically I just need clarification on what you are looking for. I can write a simpler version of the existing websocket server for clarity. Or perhaps you would like the client and server swapped? This way the golang side is constantly running as a server and js clients can connect to it.

[clouedoc]

First of all, thanks for your prompts response.

What we are looking for is not a change to how CycleTLS works internally.
We are looking for a way to communicate with an external WS server while still using CycleTLS' mimicking.

My apologies for this misunderstanding 😓.

Here's what I envision (these are internal typings -- I can commit them if you want)

import {
  CycleTLSMethod,
  CycleTLSRequestOptions,
  CycleTLSResponse,
} from "./cycletls";

export interface CycleTLSClient {
  // HTTP Methods
  (
    url: string,
    options: CycleTLSRequestOptions,
    method?: CycleTLSMethod
  ): Promise<CycleTLSResponse>;
  head(url: string, options: CycleTLSRequestOptions): Promise<CycleTLSResponse>;
  get(url: string, options: CycleTLSRequestOptions): Promise<CycleTLSResponse>;
  post(url: string, options: CycleTLSRequestOptions): Promise<CycleTLSResponse>;
  // and all the other HTTP request methods

  // WebSocket methods (API to be decided)
  openWSConn(url: string, opts: CycleTLSWSOptions): Promise<{ connId: string }>
  onWSMessage(connId: string, cb: (msg: CycleTLSWSMessage) => Promise<void>): void
  removeWSListener(connId: string): void
}

/**
  * A WebSocket message received by the CycleTLS client.
  */
export interface CycleTLSWSMessage {
  // not important but it may be useful to someone, someday
  connId: string;
  
  // message content and metadata
  opcode: WSOpcode;
  body: Buffer;
  // and other properties I totally forgot about
}

export WSOpcode { 
  // not actual opcodes
  OK = 1,
  WAITING = 2
  FOO = 3
  BAR = 4
}

the golang side is constantly running as a server and js clients can connect to it.

I don't have a deep understanding of how CycleTLS works right now, to be honest. We're two people on the project and I'm not the one working directly with it.

That being said, I think that GoServer+JSClient is better than JSServer+GoClient because of memory issues which would arise with launching a lot of Go executables.

Go Implementation suggestions

If I remember correctly, connecting to WS in Go is a bit archaic, but it could be useful for our usecase :)

You need to first make the HTTP request by using "net/http" and pass the *net.Conn to a WS library.

So the way to do it would be to make the HTTP upgrade request with CycleTLS and then passing the Conn the a WS library.

What do you think about this?

[Danny-Dasilva]

Got it, I'm familiar with implementing a go socket server (I use a go socket server for testing against the cycleTLS client). I will implement this most likely with a command line option for server mode. E.g. ./index.go --server where the server will just be waiting for websocket connections. Expect a rough version of this within a week or two.

[clouedoc]

Sounds great, but it's not the feature we're looking at! My apologies for persisting this misunderstanding.

./index.go --server where the server will just be waiting for websocket connections

This is certainly a better architecture for CycleTLS, but it's not what we're concerned about.

We are looking for the addition of the WebSocket protocol in CycleTLS <-> target communications (along the HTTP(S) protocol)

Here's another diagram I made:

Expect a rough version of this within a week or two

We are still interested in sponsoring your work, by the way 🙂

[Danny-Dasilva]

This diagram is a lot more clear. Implementing this should be relatively easy. I'll reach out to you privately once I get started (there's still some bugs I'm aware of in cycleTLS). We can discuss sponsorship then as well as implementation testing.

[clouedoc]

Sounds great, I'll be waiting for your email 🙂

About testing, I don't really have an idea of how it would go since JA3 fingerprinting happens when first connecting via TLS (if I'm not mistaken).

Said in an other way, if we can control how the net.Conn is created + the 101 Switching Protocol request, we're stealth.

[rubengp99]

Any update on this?

[lortonx]

Any update on this?