关于通过MITM实现自定义Browser Dialer内层 HTTP host header（domain fronting）的一种猜想？

[Kc2353]

如题，对浏览器安装证书，设置代理经过core MITM之后重新发出，关于在有Proxy时特征可能不一致的问题，可以学scholar edu cn强制FakeIP
本人学艺不精，想知道一下TLS里面是否存在“如果不知道浏览器内存里面的session key等密钥就完全无法模仿”的指纹特征？

[RPRX]

经过 Xray-core MITM 后就变成了 Go/uTLS 的 TLS 栈，所以不行，不同 TLS 栈的实现特征和解不解密是两回事，解密了也难以模仿

浏览器支持把最终的对称加密 key 导出到文件，可以解密后替换里面的 HTTP host 再加密回去，不过长度可能会变化，而且有点麻烦

会不会引起浏览器内部状态错误需要测试，并且这样一来又要经过一次 Xray Freedom/Direct，并不是首选吧，虽然 TUN 本来就会

---

前情提要：https://t.me/projectXtls/2724

这次 v2rayNG 主要是多了 XHTTP packet-up 的浏览器转发，相较于 WSS 解决了 ALPN 问题、且能过更多 CDN、支持上下行分离与 header padding 等，优选域名通过改 DNS/hosts 可以实现，QUIC 和 ECH 理论上也可以调出来，目前急需解决的问题只剩浏览器禁止了自定义内层 HTTP host header（domain fronting），有人能解决的话奖励一个 Project X NFT，需要重新编译 Chromium 的不算

https://chromium-review.googlesource.com/c/chromium/src/+/4867872 删掉了 --host-rules 参数，或许它能回来

https://t.me/projectXtls/2724?comment=4957029
https://t.me/projectXtls/2724?comment=4957348
https://t.me/projectXtls/2724?comment=4958729

[RememberOurPromise]

--host-rules
这个参数好像是以前用来绕过SNI阻断的，用这个方法SNI和host都会改，达不到域前置效果

[RPRX]

https://t.me/projectXray/4958926 @SpaceTimee 有评论，应该是能 domain fronting 的吧

[RememberOurPromise]

找了个旧chrome重新抓包看了下确实是可以domain fronting

--host-rules="MAP *youtube.com g.cn" --host-resolver-rules="MAP g.cn 1.2.3.4," --test-type --ignore-certificate-errors

Claude总结:

这些 Flag 实际做了什么

Flag	作用层	效果
--host-rules	Chrome 网络栈	在建立连接前将SNI重写
--host-resolver-rules	DNS 解析层	将特定域名解析到指定 IP
--ignore-certificate-errors	TLS 验证层	忽略证书不匹配错误
--test-type	UI 层	压制安全警告横幅

你的命令执行链路是：

请求 youtube.com
  → --host-rules 重写为 g.cn
  → --host-resolver-rules 将 g.cn 解析到 1.2.3.4
  → TCP 连接建立到 1.2.3.4
  → TLS SNI = g.cn（重写后的域名）
  → HTTP Host = youtube.com
  → 证书不匹配 → --ignore-certificate-errors 强行忽略

[RPRX]

常规的 --host-rules 应该不需要 --ignore-certificate-errors 吧

--host-resolver-rules 可以优选 IP

所以说 Chrome 本来啥都有，硬是被那个 PR 给改残了

[RememberOurPromise]

QUIC 和 ECH 理论上也可以调出来

QUIC

--origin-to-force-quic-on=example.com:443

https://chromium.googlesource.com/playground/chromium-org-site/+/refs/heads/main/quic/playing-with-quic.md
https://codereview.chromium.org/1808303005

ECH

强制等候HTTPS记录查询

--enable-features="UseDnsHttpsSvcb:UseDnsHttpsSvcbEnforceSecureResponse/true"

Param to control whether or not HostResolver, when using Secure DNS, will fail the entire connection attempt when receiving an inconclusive response to an HTTPS query (anything except transport error, timeout, or SERVFAIL). Used to prevent certain downgrade attacks against ECH behavior.

此参数控制 HostResolver 在使用安全 DNS 时，如果收到 HTTPS 查询的不确定响应（传输错误、超时或 SERVFAIL 以外的任何响应），是否会终止整个连接尝试。用于防止针对 ECH 行为的某些降级攻击。

然后用这个，HTTPS记录可以加一个alpn只写h3
ECH暂时没法用参数或者flags

[RPRX]

ECH 的话，Xray 接管 DNS 然后 hijack type 65 也行 #5981 (comment) @Meo597 ，话说 Chrome 会给 UDP 53 DNS 发 type 65 的吧

我标这个 PR welcome，更希望是有缘人去给 Chromium PR 回 --host-rules，以及先进的 ECH 控制，比如指定某域名拿别的域名查

[Fangliding]

用chrome自带flag搞域前置这一套很久之前已经有人玩过了啊

[RPRX]

这不是 GFW 开始上强度了嘛，以前 Browser Dialer 只是概念性验证，以后可能要大规模用起来了

支持 domain fronting 的话利好伊朗 XHTTP https://t.me/projectXtls/2729 https://t.me/projectXtls/2734 ，甚至利好 XDRIVE #5645

[Meo597]

ECH 的话，Xray 接管 DNS 然后 hijack type 65 也行 #5981 (comment) @Meo597

在 TODO 里了#5947 (comment)

[yyyytawa]

常规的 --host-rules 应该不需要 --ignore-certificate-errors 吧

--host-resolver-rules 可以优选 IP

所以说 Chrome 本来啥都有，硬是被那个 PR 给改残了

简单,你再 PR 改回来就行

[yyyytawa]

这不是 GFW 开始上强度了嘛，以前 Browser Dialer 只是概念性验证，以后可能要大规模用起来了

支持 domain fronting 的话利好伊朗 XHTTP https://t.me/projectXtls/2729 https://t.me/projectXtls/2734 ，甚至利好 XDRIVE #5645

nginx Dialer 如何,应该不管 OpenSSL 的指纹

[Kc2353]

nginx Dialer 如何

我觉得对于普通人，在客户端nginx应该不算正常(谁家好人天天套nginx上网啊)，但也算不上很像翻墙特征；但是在中转服务器的话，nginx特征应该比浏览器特征好一些，就看墙是否把“源IP是个人用户还是IDC”作为一个判定点了