Closed emdaitaj closed 1 year ago
你的建议很好,支持一下这个建议
Do u mean golang fingerprint itself is banned?
Yes, this is what I also believe, however I have not made a new server to test the hypothesis. My current server does not work on some mobile operators in Iran, but it works with ADSL (home connection), all with utls not enabled.
My suspicion is that they are banning/blocking the golang fingerprint on mobile networks when TLS header Certification status / TLS Handshake Client Hello is sent.
Do u mean golang fingerprint itself is banned?
yes , when long/large transfer is made using golang fingerprint , the government censorship firewall detects it's v2ray/xray and not some go code running ... detected in one day
they even have slowwed down chrome/firefox fingerprint , randomized works fast
这是个很好的提议,不过需要好好想一下实现细节,否则会成为一个可以被探测的特征。另外,实现拒绝特定客户端 TLS 指纹的功能必须要 Xray-core 前置(不知道 Nginx、Caddy 等有没有对应的插件),但这样的话服务端 TLS 指纹基本上是 Go 的默认指纹,与 Nginx、Caddy 等更常用的软件不同(虽然直接用 Go 起 HTTPS 服务的人也不少)。
所以,我建议你直接用不久后会推出的 Reality 协议,它可以解决服务端 TLS 指纹的问题并满足你的需求。
@RPRX 温馨提醒,距离新年(春节)还有四天,期待新年礼物。
这是个很好的提议,不过需要好好想一下实现细节,否则会成为一个可以被探测的特征。另外,实现拒绝特定客户端 TLS 指纹的功能必须要 Xray-core 前置(不知道 Nginx、Caddy 等有没有对应的插件),但这样的话服务端 TLS 指纹基本上是 Go 的默认指纹,与 Nginx、Caddy 等更常用的软件不同(虽然直接用 Go 起 HTTPS 服务的人也不少)。
所以,我建议你直接用不久后会推出的 Reality 协议,它可以解决服务端 TLS 指纹的问题并满足你的需求。
to not make it a detectable feature, we dont drop the connection, we serve it like a client with wrong password (direct fallback)
we dont neeed nginx/caddy... plugins , we just implement it for direct xray-core tcp+tls streams ,in which xray-core directly listens on port and manages incoming connections
interested in hearing more about the Reality protocol
to not make it a detectable feature, we dont drop the connection, we serve it like a client with wrong password (direct fallback)
这样做有一个小问题是,客户端大概率会关闭连接,不过 Reality 不会。
we dont neeed nginx/caddy... plugins , we just implement it for direct xray-core tcp+tls streams ,in which xray-core directly listens on port and manages incoming connections
我的意思是,如果 Nginx、Caddy 等有拒绝特定客户端 TLS 指纹的插件(且你的代理协议不需要 Xray-core 前置的话),直接用它们来实现目标,服务端 TLS 指纹就不会是 Go 的默认指纹。否则,就需要解决服务端 TLS 指纹的问题。
interested in hearing more about the Reality protocol
两年前我对它有一个模糊的想法,不过不久前我才重启它的设计。协议设计最花时间,目前已经定型,不得不说和两年前的模糊想法差别还是挺大的。增量代码不多,已完成最核心的部分,剩下的事情主要是 Xray-core 接入它,以及写一篇文章介绍它。
太棒了 成功给R佬增加了一个重担:写文档 ~这重担大厂干过的同学都懂~
@RPRX
若用 HaProxy 前置的話,只有付費的企業版才有增加 tls fingerprint 探測插件的功能;但若 HaProxy 前置並開啟 tls termination,又沒有企業版加身,這可咋辦?
Edit: 查了一下,社區版的 HaProxy 也可以用配置來生成 JA3 / TLS fingerprint,但不知道具體當如何配置,才能實現隱蔽 go tls 特徵的功能。可有這方面的規則/實例可供探究的嗎?
to not make it a detectable feature, we dont drop the connection, we serve it like a client with wrong password (direct fallback)
这样做有一个小问题是,客户端大概率会关闭连接,不过 Reality 不会。
we dont neeed nginx/caddy... plugins , we just implement it for direct xray-core tcp+tls streams ,in which xray-core directly listens on port and manages incoming connections
我的意思是,如果 Nginx、Caddy 等有拒绝特定客户端 TLS 指纹的插件(且你的代理协议不需要 Xray-core 前置的话),直接用它们来实现目标,服务端 TLS 指纹就不会是 Go 的默认指纹。否则,就需要解决服务端 TLS 指纹的问题。
interested in hearing more about the Reality protocol
两年前我对它有一个模糊的想法,不过不久前我才重启它的设计。协议设计最花时间,目前已经定型,~不得不说和两年前的模糊想法差别还是挺大的~。增量代码不多,已完成最核心的部分,剩下的事情主要是 Xray-core 接入它,以及写一篇文章介绍它。
thanks ,got it
that,s great ,from the name of vision vs reality i guess it,s gonna mimic real tls connection completely and bypass any tls in tls detection technique
will wait for it i,m finished with this issues,we can close it if others dont have any questions
😏 can you close the issue
Jan 20, 2023 19:00:46 emdaitaj @.***>:
to not make it a detectable feature, we dont drop the connection, we serve it like a client with wrong password (direct fallback)
这样做有一个小问题是,客户端大概率会关闭连接,不过 Reality 不会。
we dont neeed nginx/caddy... plugins , we just implement it for direct xray-core tcp+tls streams ,in which xray-core directly listens on port and manages incoming connections
我的意思是,如果 Nginx、Caddy 等有拒绝特定客户端 TLS 指纹的插件(且你的代理协议不需要 Xray-core 前置的话),直接用它们来实现目标,服务端 TLS 指纹就不会是 Go 的默认指纹。否则,就需要解决服务端 TLS 指纹的问题。
interested in hearing more about the Reality protocol
两年前我对它有一个模糊的想法,不过不久前我才重启它的设计。协议设计最花时间,目前已经定型, 不得不说和两年前的模糊想法差别还是挺大的 。增量代码不多,已完成最核心的部分,剩下的事情主要是 Xray-core 接入它,以及写一篇文章介绍它。
thanks ,got it
that,s great ,from the name of vision vs reality i guess it,s gonna mimic real tls connection completely and bypass any tls in tls detection technique
will wait for it i,m finished with this issues,we can close it if others dont have any questions
— Reply to this email directly, view it on GitHub[https://github.com/XTLS/Xray-core/issues/1539#issuecomment-1398223721], or unsubscribe[https://github.com/notifications/unsubscribe-auth/AKGBAYEXOUZB2DL7TE3FOV3WTJV53ANCNFSM6AAAAAAT55ENCY]. You are receiving this because you are subscribed to this thread.[Tracking image][https://github.com/notifications/beacon/AKGBAYHHGLIT7HTOZQE5GJ3WTJV53A5CNFSM6AAAAAAT55ENC2WGG33NNVSW45C7OR4XAZNMJFZXG5LFINXW23LFNZ2KUY3PNVWWK3TUL5UWJTSTK4ZWS.gif]
in Iran TLS xray servers are easily detected when some lazy clients don't configure utls (shared with url not json) and the ip will get banned even if you share with json an envying person can use without utls and get your server banned on purpose
so it would be great if you can set an option on the server side to reject clients not using utls