REALITY Server TLS Fingerprinting
I am sure there is a problem with REALITY, it's getting detected so quick (even when it's sni and dest is to my own website) but using a legit tls certificate is not getting detected at all, even if i don't point the domain to my server ip or point it to something else what could be the problem? did anyone ever compared JA3S of Xray or Sing-box REALITY and Nginx?
~~看标题我还以为确定了原因,白高兴一场~~
(even when it's sni and dest is to my own website) but using a legit tls certificate is not getting detected at all
愿闻其详
~~Judging from the title, I thought the cause had been determined, but I was disappointed.~~
I'd like to hear the details.
I have tested and found no server fingerprint problem (I have not studied TLS in depth, so my analysis may not be perfect) And as i filter incoming connections, there must be no crafted packet reaching the proxy core (not sure) So how they can detect it? i don't know
Would like to hear the details
Server was Xray for both tests used gRPC for both REALITY and TLS because i need Mihomo client support for my PC, It's Tun for Desktop is a must, use-system-hosts dns setting and PROCESS-NAME rule are also necessary for me to not lose my pirated softwares lol
the TLS config difference was that it had H3 support, because i was testing XHTTP H3 maybe problem was this? because it's impossible for REALITY to support H3 so they ignored my IP because it had H3 support?
This old wiki page gives examples of extracting a TLS fingerprinting to text format. Basically, if you install Wireshark, you can run tshark with the -V option to output a text summary of the message. Then you can, for example, diff two recorded messages using standard text diff tools.
https://gitlab.torproject.org/legacy/trac/-/wikis/doc/meek/SampleClientHellos
tshark -V -2 -R ssl.handshake.ciphersuites -r file.pcap
There was a feature at tlsfingerprint.io where you could upload a pcap file, and it would extract the Client Hellos and sow you how common the fingerprints are in a campus traffic tap. But the site seems to be down as I check it just now. There is source code for the site at https://github.com/refraction-networking/tls-fingerprint, but the greater part of the value was observed fingerprint frequencies.
FYI https://github.com/XTLS/Xray-core/discussions/3269#discussioncomment-11639775
我觉得有很多可能,比如伊朗 GFW 对 REALITY 的封锁是基于 Vision / gRPC 的固有流量特征,或找到了当前 REALITY 代码的未知特征,很后悔去年没发出文章说明下原理,我觉得伊朗那边虽然有很多测试但都没有修改 REALITY 代码,都是皮毛、浮于表面
@fodhelper 能否测试一下:
- 关闭 H3,REALITY target 设为 Nginx,但不使用 REALITY,只访问 Nginx(网站)
- 关闭 H3,REALITY target 设为 Nginx,使用 REALITY Vision / gRPC / XHTTP,看看分别多久会触发封锁
- 为了确定是否有 H3 的影响,启用 H3,同时也安装并使用 REALITY,看看会不会触发封锁
也可能是基于组合的特征来封锁,比如检测到疑似 Vision / gRPC 就去主动探测一下是不是 REALITY,~~总之研究这个挺烧脑的~~
I think there are many possibilities. For example, the Iranian GFW's blocking of REALITY is based on the inherent traffic characteristics of Vision/gRPC, or it has found unknown features of the current REALITY code. I regret not issuing an article last year to explain the principle. I think that although there have been many tests in Iran, none of them have modified the REALITY code. They are all superficial and superficial.
@fodhelper, can you test the following:
- Disable H3, set REALITY target to Nginx, but do not use REALITY, just access Nginx (website)
- Disable H3, set REALITY target to Nginx, use REALITY Vision / gRPC / XHTTP, and see how long it takes to trigger the block
- To determine whether H3 has an impact, enable H3, and also install and use REALITY to see if it will trigger a block
It may also be blocked based on a combination of features, for example, if Vision / gRPC is suspected, it will actively detect whether it is REALITY. ~~In short, it's quite a brain-burning research.~~
@RPRX
or, maybe, reverse dns-mapping...
or, maybe, reverse dns-mapping...
Sure, This is a known way to detect ShadowTLS
I mean the REALITY, @RPRX renames everything, ShadowTLS to REALITY, SplitHTTP to XHTTP, makes us to forget the origin