crypto/tls: set const maxUselessRecords to 32 (the same with OpenSSL)

[RPRX]

golang/go#58913

[RPRX]

该补丁对 uTLS 的特殊意义：uTLS 模仿的指纹大多使用 BoringSSL，对应值为 32，大于 Golang TLS 的 16。比如，中间人怀疑某个 Chrome TLSv1.3 连接实际上是 uTLS，在握手完成前插入 17 个 CCS 包，却触发了 alert，则可以确定它为 uTLS。

该行为对于真 Chrome 等浏览器是没有影响的，几乎没有附带伤害，所以对 uTLS 来说比较危险。

---

The patch has special implications for uTLS: uTLS mimics fingerprints mostly using BoringSSL, corresponding to a value of 32, which is greater than Golang TLS's 16. For example, if an intermediary suspects that a Chrome TLSv1.3 connection is actually uTLS and inserts 17 CCS packets before the handshake completes, but triggers an alert, it can be determined to be uTLS. .

This behavior has no effect on browsers such as True Chrome, with little collateral damage, so it is more dangerous for uTLS.

Translated with www.DeepL.com/Translator (free version)

[gaukas]

Good catch. Let's get this merged for good.

[RPRX]

我觉得可以把对 uTLS 客户端的攻击/识别分为两类，一类是有附带伤害，即可能阻断真浏览器的连接，一类是无附带伤害，比如该 PR 提出的这种方式：实时阻断、识别 uTLS，而不会阻断真浏览器的连接。

对于前者，其实角度非常多，但审查者不一定会实施。后者更加隐蔽、危险，可以被暗中利用，我发现了一些，将逐一进行修复。

---

I think we can divide the attacks/identifications on uTLS clients into two categories, one with collateral damage, i.e., possibly blocking the connection of the real browser, and one without collateral damage, such as this approach proposed in this PR: blocking and identifying uTLS in real time, without blocking the connection of the real browser.

For the former, there are actually very many angles, but censors don't always implement them. The latter is more insidious, dangerous, and can be exploited covertly; I found a few and will be fixing them one by one.

Translated with DeepL (https://www.deepl.com/app/?utm_source=ios&utm_medium=app&utm_campaign=share-translation

[gaukas]

Much obliged! Let me know if there's anything I might be able to help with.

Also, it's good NOT to spend too much time exploiting(and patching) uTLS before evidence showing any censor does. Parrot is dead, and it may take an eternity to resurrect it.