防主动探测问题

[bash99]

请问如果把tuic监听在443端口，如果某个支持http/3协议的客户端正常访问会得到什么结果？有特征可循吗？

有无必要提供功能将请求转发到本地80端口？

[chika0801]

有无必要提供功能将请求转发到本地80端口？

没必要，也没什么程序能做这步吧。参考hy那边也没写还防什么主动探测。

[bash99]

有无必要提供功能将请求转发到本地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%了，没响应。

[chika0801]

有无必要提供功能将请求转发到本地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%了，没响应。

那你等作者怎么回复你了，我不懂这方面具体技术原理

[moranno]

可以参考下@gfw-report的主动探测测试：
XTLS/Xray-core#625 (comment)

向服务端发送指定大小的数据包，看服务端是否会有所返回，不过我刚刚想了下，这货是UDP啊，服务端响应是不是和TCP完全不一样？不太懂。

[gfw-report]

向服务端发送指定大小的数据包，看服务端是否会有所返回，

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 XTLS/Xray-core#625 (comment) or net4people/bbs#26 (comment) 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".

[EAimTY]

若存在主动探测，连接的流程会以如下方式进行：

1. server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）
2. server 端会接受 client 新建的所有 stream、datagram 并解析它们的 header。但在收到正确的 TUIC 鉴权 stream 前，server 端不会回复任何信息。如果恶意的主动探测发送的数据无法按照 TUIC command header 解析，server 会立刻切断整个 QUIC 连接
3. 由于恶意的主动探测无法发出正确的 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 协议很好的切入点，欢迎大家继续讨论这个问题。

[yuhan6665]

*ray 的历史经验 成熟的解决方案是把流量导入真正的 HTTP3 服务器 方法有两种 一种是 path 分流 一种是鉴权之后回落 但是两种都需要跟 h2c 类似的 h3c 我之前没看见过 可能将来会有。。
有一个临时的想法是把 quic 解密 然后如果不是代理流量就重新加密送 http3 服务

[bash99]

若存在主动探测，连接的流程会以如下方式进行：

1. server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）

我的疑问在于，在client和server第一次建立链接时，是否 alpn和sni信息还是明文的，而主动探测方做DPI拿到这些信息重发http/3请求，又没有得到正常的http响应，是否就能辨别该端口跑了一个quic协议但是不是web server的服务。可能未来这种服务会挺多，但是现在可能quic协议主要承载了http/3流量。

[moranno]

若存在主动探测，连接的流程会以如下方式进行：

1. server 与 client 建立 QUIC 连接（需要证书与 ALPN 匹配）

我的疑问在于，在client和server第一次建立链接时，是否 alpn和sni信息还是明文的，而主动探测方做DPI拿到这些信息重发http/3请求，又没有得到正常的http响应，是否就能辨别该端口跑了一个quic协议但是不是web server的服务。可能未来这种服务会挺多，但是现在可能quic协议主要承载了http/3流量。

对...这其实也是一种重防攻击？不过关于重放攻击，TLS默认应该是防重放攻击的吧？

[tianlichunhong]

如果鉴权不通过，server是否可以不给任何答复原因，直接掐断？不要以网页的思路去考虑，难到数据库加密的流量，也需要回复鉴权不通过的流量吗？我觉得给答复，总会暴露一些信息，从这些信息又可以判断更多情况，比如域名（如域名不在白名单中，GFW会直接掐断）。

[EAimTY]

最近正在重构，打算按照鉴权失败回落 HTTP/3 的方式处理。从 stream 读取 TUIC header 尝试解析并失败后，交给 HTTP/3 服务的 stream 仍应该包含 header 中的内容，但是目前遇到的问题是上游的 quinn 没有实现 AsyncSeek 相关的 API。我之后打算单独写一个基于 AsyncRead 实现 AsyncSeek 的库，但目前还不确定能否实现。

之后的 TUIC 本身打算以库的形式发布，包含上面所说的解析失败后将 stream 转交的 API。server 与 client 的实现会基于这个库，但我的这个实现追求最小化，因此大概不会在 server 实现内加入 HTTP/3 相关的东西。

[moranno]

此次大批量封443，TUIC也中弹了

请问是你的tuic服务器中弹吗？部署tuic之前是否还运行过其他代理程序？
还是别人的案例报告？