utls packages in dpi iran

[realartin]

hi there
tnx for your great work

according to this tweet
https://twitter.com/uo0sef/status/1668080992052027392?t=cNSQWkDTozhMT9QVOaOHUg&s=19

there is an experiment done by uosof that proves dpi in iran can define utls sign packages !

please if it possible make a way for iranian folks that really need your help ❤️🙏

[us254]

(https://twitter.com/uo0sef/status/1668080992052027392)

"It appears that the signatures of the 'utls' package are being detected by DPI (Deep Packet Inspection). In my code, when I use Chrome's signing feature, the client's request for 'utls' is flagged as a malformed packet, indicating an issue with the format or structure of the packet. However, when I use 'Android OkHttp', the same issue doesn't seem to be recognized."
()

[us254]

不过，现在我们对 uTLS 的使用方式，包括 uTLS 本身确实是存在一些问题，在把它们修复之前，我倾向于不说出来

net4people/bbs#257 (comment)

[hawshemi]

Yes. some of the Signatures are detected by Iran's GFW and blocked (or interestingly, on some ISPs line MTN, the GFW makes the ping and jitter 5x worse!!!)

[RPRX]

不过，现在我们对 uTLS 的使用方式，包括 uTLS 本身确实是存在一些问题，在把它们修复之前，我倾向于不说出来

net4people/bbs#257 (comment)

我还是说一下吧，如果 仅观测 单个连接，对于绝大多数网站，我用 WireShark 看过 uTLS 的 Chrome 指纹是没问题的，但是：

1. 若实时干涉，有很多方法能让 uTLS 露馅，但这对连接可能是破坏性的
2. 若观测多个连接，现在我们对 uTLS 的使用有一些统计特征，比如说，部分网站会发 Sesssion Ticket，现在我们当没看见
   不过（好像是）RFC 8446 也说了这个机制会导致观测者关联不同的连接，所以 Chrome 是仅用一次，需要我们模仿
3. 对于极少部分网站，比如 dl.google.com，Chrome 的 Client Finished 会附加额外信息，而 uTLS 的相关机制并不完善

不过这个 issue 显然不是上述问题，但好像也没说细节，如果确实有问题且能定位到细节，可以去给 uTLS 提 issue 或发 PR。

[RPRX]

补充，序号对应：

1. 我倾向于主要防范非破坏性的干涉，比如 crypto/tls: set const maxUselessRecords to 32 (the same with OpenSSL) refraction-networking/utls#171 （至于 crypto/tls: reject change_cipher_spec record after handshake in TLS 1.3 refraction-networking/utls#170 ，它主要是 Golang crypto/tls 的 bug，不过 Golang 至今没有任何回复）
2. 参考 https://trac.nginx.org/nginx/ticket/1892
3. REALITY example 提到了 dl.google.com，就是举个栗子，不会真的有大聪明 dest 用 Google 吧

[nursery01]

Sesssion Ticket，现在我们当没看见
不过（好像是）RFC 8446

RFC 8446你是哪裡能弄到正常人版本嗎？原版太難讀了，難讀不是因為英文，而是因為它是碎片化拼湊組織語言

[RPRX]

Sesssion Ticket，现在我们当没看见
不过（好像是）RFC 8446

RFC 8446你是哪裡能弄到正常人版本嗎？原版太難讀了，難讀不是因為英文，而是因為它是碎片化拼湊組織語言

我看的是原版，其实我觉得还好，多看就熟悉了

[nursery01]

我看的是原版，其实我觉得还好，多看就熟悉了

你是用翻譯看的吧😜，就8446怪，RFC 9114的都挺正常聽好讀的

[RPRX]

我看的是原版，其实我觉得还好，多看就熟悉了

你是用翻譯看的吧😜，就8446怪，RFC 9114的都挺正常聽好讀的

不是翻译，不过我没有通读过，我一般是先看目录或搜关键词，只挑感兴趣的部分看，本身就是碎片化，时间久了就集齐碎片了

[chika0801]

不会真的有大聪明 dest 用 Google 吧

搬运 https://t.me/projectXray/2058996

我猜有很多人（比如我）用 dl.google.com

[RPRX]

不会真的有大聪明 dest 用 Google 吧

搬运 https://t.me/projectXray/2058996

我猜有很多人（比如我）用 dl.google.com

其实针对 dl.google.com 不用 Chrome 指纹即可，这个给我感觉是典型的 Google 自家产品一唱一和做实验，就像 SPDY 和 QUIC

[realartin]

不会真的有大聪明 dest 用 Google 吧

搬运 https://t.me/projectXray/2058996

我猜有很多人（比如我）用 dl.google.com

其实针对 dl.google.com 不用 Chrome 指纹即可，这个给我感觉是典型的 Google 自家产品一唱一和做实验，就像 SPDY 和 QUIC

On behalf of myself and all my compatriots, I express my deepest gratitude to you

If you need a server in Iran to test Iran's dpi, contact me

[TheArshiyan]

@RPRX reality is being detected in Iran from almost 4 days ago, I don't know how they detect reality mechanism but I'm sure that I've configured my server exactly as you said in the repo(fallbacks,shortIDs, etc). it would be great if you take a look and give us some details so we can find a solution for this. we need your help. best regards

[gaukas]

Welp, seemingly this is a mirror issue to utls#193. In case people are still wondering, I'd make a clarification to the original issue.

TL;DR: No, this error is not caused by a censor interfering uTLS.

This "malformed HTTP response" error is due to client using HTTP/1.1 round-tripper on a TLS connection negotiated for HTTP/2 (via ALPN extension). And it has nothing to do with uTLS being identified or uTLS being blocked by any kinds of techniques.