TLS ECH client: Use chrome-fingerprint and add padding; Add "h2c" and echSockopt; Fix some issues

[patterniha]

1. currently we can't use: dialer, built-in-dns, socket-keepalive, happyeyeballs, ... for ech.
   in fact, we couldn't set sockopt for ech, so i add echSockopt.
   the format is exactly streamSettings-sockopt.

2. add h2c for ech, so with sockopt-dialerProxy that added in 1, we can use ech for ech-DOH, domain-fronting, and in general we can use our custom-tls.

3. now ech-DOH use chrome-fingerprint

4. fromMitM serverName should be set before calling ApplyECH

5. add X-Padding header to ech-DOH

///

"echConfigList": "example.com+h2c://1.1.1.1/dns-query",
"echSockopt": {
       "domainStrategy": "forceIP",
       "dialerProxy": "outbound-2",
       ...
}

[RPRX]

@patterniha 正好我都有点忘了当初我对 DoH 都改了啥，还有 fromMitm 什么的，帮我回忆下

[patterniha]

@RPRX

if serverName set to fromMitM, serverName should be replaced with the decrypted-tls-sni(in dokomo-MitM), but after adding ech, it was replaced after calling ApplyECH, so ech use wrong name.

I fix it, there is no need to do anything else.

///

for DOH:

1. you add body-padding because of DNS: Retry with EDNS0 when response is truncated  #4516 (comment)
   

   Xray-core/app/dns/nameserver_doh.go

   Line 135 in c569f47

   reqs := buildReqMsgs(domain, option, s.newReqID, genEDNS0Options(s.clientIP, int(crypto.RandBetween(100, 300))))

2. you add header-padding:
   

   Xray-core/app/dns/nameserver_doh.go

   Line 200 in c569f47

   req.Header.Set("X-Padding", strings.Repeat("X", int(crypto.RandBetween(100, 1000))))

3. you add chrome-fingerprint:
   

   Xray-core/app/dns/nameserver_doh.go

   Lines 102 to 104 in c569f47

   	if !h2c {
   	conn = utls.UClient(conn, &utls.Config{ServerName: url.Hostname()}, utls.HelloChrome_Auto)
   	if err := conn.(*utls.UConn).HandshakeContext(ctx); err != nil {

///

i add header-padding and chrome-fingerprint to ech-DOH, but it still doesn't have body-padding.

[Fangliding]

各种乱七八糟的padding喜欢加可以加 不过这个doh并没有那么高的query流量 大多数情况下查一个非常接近一个普通查询 没普通dns问题严重

[RPRX]

@patterniha DoH 时 body-padding 要加的，不然一看返回 body 长度就知道这是在查 ECH

[RPRX]

@Fangliding 盲猜 ECH 查询比普通 A/AAAA 查询的响应长 50+ 字节，你用 WireShark 看下

[patterniha]

@RPRX

I haven't read the code related to body-padding yet, I will try to read it to see what happened in ip-DOH and add it to ech-DOH

[Fangliding]

padding的是请求 和返回的响应是什么没关系 还有HTTPS响应反而短一点点

[RPRX]

@Fangliding DoH 的 body-padding 开了时，“it MUST pad the corresponding response”，我们讨论过 #4516 (comment)

[RPRX]

还有HTTPS响应反而短一点点

是这样的吗，我想着它随便发个公钥不比发几个 IPv4/v6 长吗，还是没上抗量子的锅，不过上了抗量子的话得到一千。。。

[Fangliding]

下面不是还有吗 padding到定长字节 响应长了的话padding的部分会自动缩减 所以跟响应长度没啥关系 哪怕响应是真长了点也还是返回那么多body

[RPRX]

@Fangliding 我的意思就是响应没 body-padding 的话，学 GFW 在外面用 WireShark 看应该能看出区别

[Fangliding]

都是468 这肯定不会出问题 人家的dns又不是ray里土制的A/AAAA特化 所有记录都是这个行为

[RPRX]

#4949 (comment)

我的意思是 DoH 请求的 body-padding 会影响响应，所以 #4949 (comment)

[RPRX]

@patterniha rebase 然后加上 body-padding，我晚点看一下

[patterniha]

new changes:

6. add body-padding
7. fix number 1 in TLS ECH client: Add echForceQuery config #4947 (comment)
8. fix TLS ECH client: Add echForceQuery config #4947 (comment)
9. fix number 2 in TLS ECH client: Add echForceQuery config #4947 (comment)
10. add accept-header for ech-DOH (Section 5.1 of RFC 8484 states that DoH clients MUST include the Accept: application/dns-message)

[patterniha]

ready

[RPRX]

我再改个标题重新合一下

[RPRX]

好了，好壮观