关于使用alpn探测TCP-TLS/XTLS代理的想法

[ghost]

我想到一种使用alpn主动探测TCP-TLS/XTLS代理的方法，不知可不可行，故发在讨论区，欢迎大家讨论。
已知目前Xray/V2Ray对TCP-TLS/XTLS方式的代理，不对alpn做任何检查，即客户端与服务端的alpn无论如何设置，都能正常与服务器连接。而目前Xray/V2Ray又没有使用ESNI和ECH(Encrypted Client Hello)，即alpn是明文，所以我想的想法是：

在客户端与服务端进行TLS握手的过程中，拦截客户端的Client Hello，与服务端的Server Hello，修改其中的alpn信息，使客户端与服务端进行错误的协议协商。对其它数据不做任何修改，然后让两者继续通讯。如果连接依然正常如故，则大概率是TCP-TLS/XTLS代理。

比如，当服务端和客户端的alpn都为"h2","http/1.1"时，Client Hello不做修，改拦截并修改Server Hello alpn为"http/1.1"。这时，客户端认为自己与服务端进行http/1.1连接，服务端认为自己与客户端进行h2连接。对于一个正常的应用而言，会发生错误，比如curl：curl: (1) Received HTTP/0.9 when not allowed。但如果这是一个TCP-TLS/XTLS的代理，则连接依然正常如故，不受影响。
如果以上方法可行，那么这个方法同样可以用来探测gRPC，正常应用的gRPC alpn应该是"h2"，但为了配合uTLS，gRPC的alpn常常设为"h2","http/1.1"。拦截并修改Client Hello alpn为"http/1.1"。此时如果是正常应用，则服务端与客户端以http/1.1通讯。如果连接断开，则大概率为gRPC代理。
但以上都是我个人的猜想，因为拦截并修改alpn信息比较麻烦，没有经过实验验证

[RPRX]

仔细看了一下，描述有问题，如果修改的是 TLS Client Hello 的 ALPN，最后协商出来的是 http/1.1，客户端不会使用 h2

[ghost]

对于客户端而言，不是应该是这样：
它知道自己发送了"h2","http/1.1"，然后它收到的Server Hello也是"h2","http/1.1"，所以客户端协商出来是h2

[RPRX]

客户端收到的 Server Hello 应该只有 http/1.1 吧？

[ghost]

我对alpn协商过程也不是很熟悉。我原以为是服务端和客户端各自把自己支持的所有http协议按优先级列在alpn里发送。然后在服务端与客户端再各自进行计算协商。
如果说客户端收到的 Server Hello 应该只有 http/1.1 的话，那就把Server Hello 也篡改一下即可。

[RPRX]

我觉得 Caddy 和 Nginx 的表现会不同

[ghost]

学习了一下alpn协商过程，更新了描述