tuic
tuic copied to clipboard
EAimTY
防主动探测问题
请问如果把tuic监听在443端口，如果某个支持http/3协议的客户端正常访问会得到什么结果？有特征可循吗？
有无必要提供功能将请求转发到本地80端口？
有无必要提供功能将请求转发到本地80端口？
没必要，也没什么程序能做这步吧。参考hy那边也没写还防什么主动探测。
docker run -it --rm ymuski/curl-http3 curl --http3 https://cloudflare-quic.com/
可以测
我把地址换成自己的caddy（开了 experimental_http3 )，正常返回 页面， caddy关闭 experimental_http3 之后再跑，响应是
curl: (7) quiche: recv() unexpectedly returned -1 (errno: 111, socket 5)
而启动tuic监听443端口，curl直接卡死，cpu 100%了，没响应。
有无必要提供功能将请求转发到本地80端口？ 没必要，也没什么程序能做这步吧。参考hy那边也没写还防什么主动探测。
docker run -it --rm ymuski/curl-http3 curl --http3 https://cloudflare-quic.com/可以测
我把地址换成自己的caddy（开了 experimental_http3 )，正常返回 页面， caddy关闭 experimental_http3 之后再跑，响应是
curl: (7) quiche: recv() unexpectedly returned -1 (errno: 111, socket 5)而启动tuic监听443端口，curl直接卡死，cpu 100%了，没响应。
那你等作者怎么回复你了，我不懂这方面具体技术原理
可以参考下@gfw-report的主动探测测试： https://github.com/XTLS/Xray-core/issues/625#issuecomment-955949568
向服务端发送指定大小的数据包，看服务端是否会有所返回，不过我刚刚想了下，这货是UDP啊，服务端响应是不是和TCP完全不一样？不太懂。
向服务端发送指定大小的数据包，看服务端是否会有所返回，
You are right that the easiest way to figure out if there's an active probing weakness is to send the probes yourself and observe the reactions from the server.
不过我刚刚想了下，这货是UDP啊，
The steps in https://github.com/XTLS/Xray-core/issues/625#issuecomment-955949568 or https://github.com/net4people/bbs/issues/26#issuecomment-870342990 still work here. The only difference is that you need a --udp flag on ncat because you want to send the payload over UDP:
(python3 -c "print('a' * 50, end='')"; cat) | ncat -v --udp 127.0.0.1 12345
服务端响应是不是和TCP完全不一样？不太懂。
You can open up a tcpdump or wireshark to observe the server's reaction.
The local experiment above will help you will understand the server's reaction to probes of different length. If you want to determine if its reaction is indeed a weakness that can be exploited by the censor to identify circumvention servers, you need to measure how this reaction is different from other non-circumvention server's reaction on the Internet. This second step usually requires a horizontal scan like what Frolov et al. did; however, sometimes you don't need the second step to take a guess like "that's a very unique reaction from the server. It is likely to be a weakness that can lead to detection".
若存在主动探测，连接的流程会以如下方式进行：
- server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）
- server 端会接受 client 新建的所有 stream、datagram 并解析它们的 header。但在收到正确的 TUIC 鉴权 stream 前，server 端不会回复任何信息。如果恶意的主动探测发送的数据无法按照 TUIC command header 解析，server 会立刻切断整个 QUIC 连接
- 由于恶意的主动探测无法发出正确的 TUIC 鉴权，在 authentication timeout 后 server 会切断整个 QUIC 连接
可以发现，上述流程中，只要 client 无法提供正确的 TUIC 鉴权信息，server 就不会回复任何信息，这一点保证了 TUIC server 不会主动泄漏自己的身份。
但是，尽管 server 不会主动回复，但它可能会在主动切断 QUIC 连接时暴露身份，因为 server 会向 client 报告错误原因。这一点我之前确实没有想到，后续会更新协议。
另外，TUIC 存在下面三个行为：
- server 在收到鉴权前不会回复任何信息
- server 会在固定的鉴权超时时间后断开连接
- server 在收到任何无法按 header 解析的数据都会立即切断连接
这三个行为可能会被作为 TUIC 的特有行为被主动探测并识别，因此可能需要引入其它 mimic 正常 HTTP3 或其它基于 QUIC 的大众协议的特性。
我不知道基于上述 3 种行为探测 TUIC 是否可行。这是完善 TUIC 协议很好的切入点，欢迎大家继续讨论这个问题。
*ray 的历史经验 成熟的解决方案是把流量导入真正的 HTTP3 服务器 方法有两种 一种是 path 分流 一种是鉴权之后回落 但是两种都需要跟 h2c 类似的 h3c 我之前没看见过 可能将来会有。。 有一个临时的想法是把 quic 解密 然后如果不是代理流量就重新加密送 http3 服务
若存在主动探测，连接的流程会以如下方式进行：
- server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）
我的疑问在于，在client和server第一次建立链接时，是否 alpn和sni信息还是明文的，而主动探测方做DPI拿到这些信息重发http/3请求，又没有得到正常的http响应，是否就能辨别该端口跑了一个quic协议但是不是web server的服务。可能未来这种服务会挺多，但是现在可能quic协议主要承载了http/3流量。
若存在主动探测，连接的流程会以如下方式进行：
- server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）
我的疑问在于，在client和server第一次建立链接时，是否 alpn和sni信息还是明文的，而主动探测方做DPI拿到这些信息重发http/3请求，又没有得到正常的http响应，是否就能辨别该端口跑了一个quic协议但是不是web server的服务。可能未来这种服务会挺多，但是现在可能quic协议主要承载了http/3流量。
对...这其实也是一种重防攻击？不过关于重放攻击，TLS默认应该是防重放攻击的吧？
让TUIC作为一个正常Http3服务器去工作，除非鉴权成功，不然不会返回和代理协议有关的回应
这一行为改成以下行为似乎会更好？（欢迎讨论）
- server 会在固定的鉴权超时时间后断开连接
-
鉴权超时以后请求立即由 反向代理模块/其他http服务器 处理
-
建立quic连接（鉴权失败）后连接内所有数据全部转发到 反向代理模块/其他http服务器 由这些服务返回http错误信息（断连行为和上游同步
-
在收到任何无法按 header 解析的数据立即切断连接
如果鉴权不通过，server是否可以不给任何答复原因，直接掐断？不要以网页的思路去考虑，难到数据库加密的流量，也需要回复鉴权不通过的流量吗？我觉得给答复，总会暴露一些信息，从这些信息又可以判断更多情况，比如域名（如域名不在白名单中，GFW会直接掐断）。
Hysteria 那边同样存在主动探测的问题，参考我在其 Issue 中的回复：https://github.com/HyNetwork/hysteria/discussions/418
- server 会在固定的鉴权超时时间后断开连接
@EAimTY 隔壁 VMess 协议经历过类似问题，可参考：https://github.com/v2ray/v2ray-core/issues/2542
当然我认为在鉴权失败后，将请求转交给真实的 HTTP/3 服务处理最稳妥（也就是回落）。
最近正在重构，打算按照鉴权失败回落 HTTP/3 的方式处理。从 stream 读取 TUIC header 尝试解析并失败后，交给 HTTP/3 服务的 stream 仍应该包含 header 中的内容，但是目前遇到的问题是上游的 quinn 没有实现 AsyncSeek 相关的 API。我之后打算单独写一个基于 AsyncRead 实现 AsyncSeek 的库，但目前还不确定能否实现。
之后的 TUIC 本身打算以库的形式发布，包含上面所说的解析失败后将 stream 转交的 API。server 与 client 的实现会基于这个库，但我的这个实现追求最小化，因此大概不会在 server 实现内加入 HTTP/3 相关的东西。
此次大批量封443，TUIC也中弹了
请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？ 还是别人的案例报告？
同一台vpc vmess+ws+tls+caddy封了443 然后弄了tuic，6小时内8443端口阵亡 然后又弄了vless+h2c+caddy，4443端口，到现在没被封，就是QOS的厉害
此次大批量封443，TUIC也中弹了
请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？ 还是别人的案例报告？
同一台vpc vmess+ws+tls+caddy封了443 然后弄了tuic，6小时内8443端口阵亡 然后又弄了vless+h2c+caddy，4443端口，到现在没被封，就是QOS的厉害
请问你的tuic是运行在8443上的吗？如果是udp8443，你如何测试的udp 8443被封呢？
我之前的tuic也以为被封了，后来才意识到udp无法使用常规的telnet或者port.ping.pe来测试，再次查看发现只是服务端挂了，重启就好了，运行服务端，观察下是否能收到客户端发来的包。
此次大批量封443，TUIC也中弹了
请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？ 还是别人的案例报告？
同一台vpc vmess+ws+tls+caddy封了443 然后弄了tuic，6小时内8443端口阵亡 然后又弄了vless+h2c+caddy，4443端口，到现在没被封，就是QOS的厉害
中弹的应该是ray而不是TUIC,这事因为ray的可能性更大，毕竟go的tls握手指纹特征太特别了,而且大流量gotls特征基本上就是跑代理，而vmwss被封又不是啥新鲜事了。
你可以给你的caddy加上 Alt-Svc "h3=":443"; ma=2592000" 然后把tuic放在443端口上， 但不要开启caddy的h3，来伪装成一个Http3故障的web服务器
此外建议443的tcp跑caddy-naiveproxy-web 服务端加了web对于主动探测的防护力基本都一样，那这样的话区别就是在客户端请求和行为部分了
至于*ray跑在h2（http2、grpc）的传输本来就很烂，基本上没有QoS的啥事，QoS一般是限制包速率，或进行主动丢包，确认被QoS请进行严谨对比测试哦
目前我所看到的有统计学意义的数据所分析的都是基于 TCP + TLS 的协议，QUIC 是否受到影响还不太清楚。TUIC 受到影响的个例可能只是数据噪声，无法就此得出结论。
我的主观推测是 QUIC 没有收到影响，因为：
- 在 TCP 上，使用 TLS 的占比很高，而在 UDP 上并非如此
- QUIC 较为深度地整合了 TLS（指从 handshake、header 上），且目前 QUIC 还未被普遍使用
综上，我认为 QUIC 流量被分析的可能性不大。
尽管如此，吸取经验，我觉得有必要在行为和数据上（如 CipherSuites）贴近 Chrome 等被大规模使用的 QUIC 实现，但这可能需要修改甚至重新实现上游的 TLS 库，工程量很大。希望后续随着社区的发展可以实现吧。
关于检测 UDP 端口：TCP 和 UDP 是两个不同的协议栈，端口号互不影响，可以重叠。可以用 python 创建一个 UDP packet echo server / client 来检测，只需要非常少的代码。
