DanielLavrushin：B4 可能把 TLS 选择解析成同域 QUIC 伪装

DanielLavrushin 说明，B4 Discovery 只让用户选择 TLS capture，却按域名映射 capture；同域同时存在 TLS 与 QUIC 时，映射顺序可能让 QUIC 内容作为 TCP fake 发出。其探针在 400 次查找中得到 QUIC 360 次、TLS 40 次，建议仅在 loadCustomPayloads 中保留 TLS capture 并补充双协议测试。

作者原文@DanielLavrushin
Problem
A TLS payload picked in Discovery's options can resolve to the same domain's QUIC capture. The QUIC bytes then go out as the TCP fake, and the set made from the result names the QUIC file.
The picker lists TLS captures only, but sends just the domain (Options.tsx#L160-L161).
loadCustomPayloads maps captures by domain with no protocol, so the last one listed wins (payloads.go#L26-L30).
ListCaptures returns one entry per protocol, in map order (manager.go#L332-L333).
The test and the deployed set agree here, so this is not a false pass like #504. The fake that was tested and installed is not the one the user picked, and it can change between runs.
Evidence
Probe, not measured on a box. With a TLS and a QUIC capture saved under one name, 400 lookups of that name returned the QUIC capture 360 times and the TLS capture 40 times. The split comes from map order, so it can differ on another box or after a restart.
Reach
It needs a TLS and a QUIC capture under one name. An upload accepts quic (capture.go#L352) and the probe API accepts both (capture.go#L142). By reading, importing a shared set with TCP and UDP fakes for one host does the same. The test gateway used for #504 holds TLS captures only, so this was not seen there.
Suggested direction
Keep only TLS captures in loadCustomPayloads, with a test that holds both protocols under one name.
Found while reviewing #508.

返回动态列表查看原文