search

rosahaj / tlsproxy

HTTP proxy with per-request uTLS fingerprint mimicry and upstream proxy tunneling. Currently WIP.
MIT License
17 stars 4 forks source link

feature: add support raw ja3 data #3

Open PandaWorker opened 5 months ago

PandaWorker commented 5 months ago

I want you to add support for specifying raw data ja3 in header per request and global config I know that utls supports generating hello client from raw ja3.

const headers = {
  'x-tlsproxy-upstream': 'socks5://localhost:1234',
  'x-tlsproxy-ja3':  '771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0'
}

What do you think about this?

May be and add return socket with upstream proxy onConnect so that you can write in one open connection with proxy and one tls session?

PandaWorker commented 5 months ago

Openning connection with upstream proxy per request may be time consuming. Therefore, I suggest opening a connection on onConnect using the tls configuration from headers onConnect

rosahaj commented 5 months ago

I want you to add support for specifying raw data ja3 in header per request and global config I know that utls supports generating hello client from raw ja3.

const headers = {
  'x-tlsproxy-upstream': 'socks5://localhost:1234',
  'x-tlsproxy-ja3':  '771,4865-4866-4867-49195-49199-49196-49200-52393-52392-49171-49172-156-157-47-53,0-23-65281-10-11-35-16-5-13-18-51-45-43-27-17513,29-23-24,0'
}

What do you think about this?

May be and add return socket with upstream proxy onConnect so that you can write in one open connection with proxy and one tls session?

This project is currently using snowflake's NewUTLSHTTPRoundTripperWithProxy function to implement a custom RoundTripper function. In order to support uTLS client composition based on a given ja3 fingerprint, it would be necessary to reimplement the function. This should be doable, but I currently don't have much time to work on that.

Openning connection with upstream proxy per request may be time consuming. Therefore, I suggest opening a connection on onConnect using the tls configuration from headers onConnect

Setting the upstream proxy and TLS fingerprint per request is the main objective of this project. In order to open a connection to the desired upstream proxy based on request headers, the request needs to be intercepted and parsed first. If you do not need to change options on each request, you'd be better off using LyleMi/ja3proxy.

PandaWorker commented 5 months ago

I want to change the fingerprint for each connection (socket) with tlsproxy, and all requests in this connection will be with the same fingerprint and one ip. I want to use a proxy balancer and have one fingerprint and one proxy session (socket) used per tlsproxy connection.

rosahaj commented 5 months ago

I want to change the fingerprint for each connection (socket) with tlsproxy, and all requests in this connection will be with the same fingerprint and one ip. I want to use a proxy balancer and have one fingerprint and one proxy session (socket) used per tlsproxy connection.

Such functionality, while certainly useful in some cases, would require a lot of effort to implement. It would require rewriting tlsproxy from scratch, without relying on goproxy or snowflake, in order to handle CONNECT requests directly. That's beyond the scope of tlsproxy and not a priority for me. It might be easier to implement this in ja3proxy, but this would also require significant changes to that project.

Furthermore, a CONNECT request only establishes a tunnel to one IP address and port. Significant performance enhancements could only be expected in cases where a large number of requests is sent to the same host, which further limits the use case for such a feature.