Upgrade trojan-go client's TLS fingerprints to some of the most popular ones #464
Conversation
We hope this change will mitigate [the large-scale blocking of TLS-based censorship circumvention protocols in China](net4people/bbs#129) since October 3, 2022. Depending on one's configuration, the Clienthello sent by trojan-go client will look like one of the following values now (rather than the [Go's TLS fingerprint](https://tlsfingerprint.io/id/ad63dbc630ad9475) in previous versions): | `fingerprint` | `sni` value specified? | TLS Fingerprint ID | | ----------- | ----------- |----------- | | Chrome (default) | Yes | [e47eae8f8c4887b6](https://tlsfingerprint.io/id/e47eae8f8c4887b6)| | Chrome (default) | No | [90ac8a1dfa3b207c](https://tlsfingerprint.io/id/90ac8a1dfa3b207c)| | iOS | Yes | [133e933dd1dfea90](https://tlsfingerprint.io/id/133e933dd1dfea90)| | iOS | No | [cff7f10f631feddd](https://tlsfingerprint.io/id/cff7f10f631feddd)| | Firefox | Yes | [7161e10829541aab](https://tlsfingerprint.io/id/7161e10829541aab)| | Firefox | No | [56fa08d84940a06b](https://tlsfingerprint.io/id/56fa08d84940a06b)|
|
不懂就問~ 為什麼沒有中國能用的edge瀏覽器的指紋？ |
Update: MS Edge does introduce new fingerprints. We will include such in the next tagged version. Microsoft Edge shares the TLS Fingerprint with Chromium. Thus, we did not explicitly include a TLS ClientHello for MS Edge. You are welcome to verify this using https://tlsfingerprint.io/ with your own pcap for MS Edge and Chromium. |
|
There is also an issue related to fingerprint and CDN #271, which I found it exists in this fork as well. Would love to see it get fixed in this fork as well |
|
I think we had an issue earlier causing uTLS failing connections to cloudflare when parroting recent Chrome fingerprints. It was due to the implementation for certificate compression is missing while Chrome's ClientHello actively advertises it. Issue mentioned above was fixed in refraction-networking/utls#95 and released in uTLS v1.1.1 |
But unfortunately, with this fork, the connection issue still exists |
So it might not be a cloudflare issue, but rather a H2 issue within Trojan-Go implementation, possibly. If possible, could you please check whether or not uTLS could perform TLS handshakes successfully with your server? |
Unfortunately, the same issue and error log, but I am using nginx to handle the SSL handshake and trojan-go is behind my nginx. I suspect that this changes need to be restored to fix the issue |
Reverting such changes may effectively break TLS Fingerprint parroting, since you may no longer advertise h2. A better way is to patch the functionality to support websocket under h2. I know the current version of uTLS may have issues with H2 under certain circumstances. |
gorilla/websocket#417 seems related. And as a temporary solution, I am thinking if it is viable to disable H2 on server ONLY. Also we need to force cloudflare's CDN nodes to disable H2 on your hostname: https://community.cloudflare.com/t/http-2-greyed-out/99786/6 By doing so, ClientHello may still advertise H2 but the negotiated ALPN will be http 1.1 due to server restrictions. |
|
You can't force Cloudflare to disable h2 from web UI, the button is greyed out (not sure if you can from other methods) But with h2 disable from AWS CloudFront, I get Looks like some other issues, maybe more investigation can be done here, but original trojan-go is fine with AWS CloudFront so probably still some other issue in this fork. |
Interesting. Seems the error happens during the TLS handshake. It would be nice if you would supply a pcap with sshkeylog for further analysis. Btw, I can confirm that uTLS works great with h2 (not ws-over-h2). |
|
用这个版本依旧被封端口,反倒是用原版的没封 |
|
原版的是 trojan-gfw 这个版的吗？ |
|
Hi, we just released uTLS v1.1.3 with added ClientHello from:
|
|
We just updated to utls v1.1.3 to support more popular browser fingerprints: d135694 In particular, Thank you @gaukas and @hwh33 for your time and efforts! That's really good work! |
|
Most of these browsers have ALPN set in their ClientHello, revealing the nominal inner protocol to an eavesdropper (mainly in TLS1.2). This results in prominent characteristics compared to cases where the eavesdropper cannot assume what is actually inside the TLS tunnel. Even though the recent massive blocking seems to be based on more simple characteristics, I think introducing TLS fingerprints from those non-browser applications is also useful to mitigate potential issues in the future--even if they are not of the top amount of traffic on the Internet, the collateral damage to blocking them would be unacceptable. |
Then I am guessing you don't want to parrot a website on your proxy server either.
Would you like to give an example/estimation or any insights, e.g., what are the top non-browser TLS applications and how popular are they? |
Even for browser-like traffic, protocol mismatch is problematic. Say, for HTTP/2, there would be plenty of control frames of typical sizes. If the eavesdropper determines H/2 is indicated by SeverHello for a TLS connection, then it is safe to expect the connection should contain repeated occurrences of TLS frames of those typical sizes and vice versa. I didn't make any investigations. How about agent programs like Telegraf, database clients, and programs running on IoT devices (update: and other popular programming languages / TLS libraries such as Python / Ruby / Kotlin / ...)? Their traffic is incomparable to browsers on the Internet. But these kinds won't be exhaustive. The more choices we have, the lower possibility that the tunnel traffic is targeted. Update: |
We thank uTLS developer @gaukas and @cheungxi for their efforts in [uTLS v1.1.5](https://github.com/refraction-networking/utls/releases/tag/v1.1.5).
其实我也有些怀疑, 墙已经拥有根据客户端特征封服务端, 或者只封客户端IP或端口. 也许有些人报的服务端被封, 可能是客户端这边被封了, 但大家很难想到封的是客户端而不是服务端 |
We thank uTLS developer @gaukas and @jmwample for their efforts in [uTLS v1.2.0](https://github.com/refraction-networking/utls/releases/tag/v1.2.0).
|
@p4gefau1t @Loyalsoldier Mind to take a look at this MR? 请问这个合并请求可以合并么？ |
你好，我用了你改过的项目，https://github.com/gfw-report/trojan-go ，比较困惑的是为何你的版本作为客户端 不支持 WS 套CDN 了呢 ？ |
|
Simply put: Go websocket library doesn't work with HTTP2 transport. While all modern web browsers would advertise HTTP2 transport in their ClientHello and most of CDN providers would therefore select HTTP2 transport in ServerHello, effectively causing websocket library to fail. |
At present, you still have problems with tls, which cannot be used without ws, even with 1.1 |
This is an old problem, which had a lot of problems with h2, and also with h2 in cf cdn. Inside, I found the third party utls for h2 in cf cdn, but none of them have updated |
Care to elaborate on it? I had an impression that at some point websocket had worked with ALPN set to HTTP/1.1 in uTLS's client hello. I could be wrong though.
Any PR back into utls would be welcome. I can get them prioritized since H2 with WebSocket seems to be playing a huge role in circumvention. |
I'll leave it to you to fix, and also suggest writing a yml update gomod and cyrpol/tls😂 |
This is really no, I changed a lot of clients with utls is the problem |
A workflow updating transient dependencies sounds legit, and I would thoroughly look into your PR. Perhaps not for crypto/tls. It is almost guaranteed for us to have merge conflicts every time syncing with the upstream(crypto/tls) due to how utls was developed in its early stages. |
Interesting. Is it failing only when using utls, or also when using crypto/tls? If you recall? |
Sorry, I've fixed it on trojan-go-fork, but please update go.mod regularly, I've turned off pr and issues |
Unfortunately, I tried your latest update, the issue still exist, in addition, it even doesn't work without CDN. My binary version is arm v5 |
trojan-go开发者你们好，
在这个pull request中，我们更新了trojan-go客户端的TLS指纹，使其与一些当下最流行的TLS指纹一致。我们希望这次更新可以缓解2022年10月3日以来的针对基于TLS翻墙软件的大规模封锁。具体来讲：
根据配置的不同，这个版本的trojan-go客户端会发送以下一种流行的Clienthello指纹。这些指纹已经不同于之前版本用Go的标准库发送的TLS指纹)：
fingerprintsni？我们无意另起炉灶维护一个分支版本的trojan-go。我们之所以发布这个release是为了用户能够立即下载使用编译后的客户端。一旦我们的pull request请求被采纳，我们将归档我们的仓库。
Dear trojan-go developers,
In this pull request, we upgrade trojan-go client's TLS fingerprint to some of the most popular ones. We hope such change will mitigate the large-scale blocking of TLS-based censorship circumvention protocols since October 3, 2022. In particular,
Depending on one's configuration, the Clienthello sent by trojan-go client will look like one of the following values now (rather than the Go's TLS fingerprint in previous versions):
fingerprintsnivalue specified?We do not intend to maintain a fork of trojan-go as a separate project. We made this release so that users can have compiled binaries to use immediately. We will archive our repo as soon as our pull request is merged to upstream.