白名单 sni 自签证书的讨论

[qingmuhy0]

先说一下我的情况吧，我是 vmess 的 ws 传输模式，服务端用的自签名的 apple.com 证书，手机上安装了对应的 CA 证书，因此出于安全原因，我没有开允许证书不安全。

然后是我碰到的怪事，白天使用的时候一直都是正常的，但只要一到晚上两三点就会出现自己域名真实有效的 ssl 证书反代的 ws 可以连接，自签的节点出现超时问题，每次我立马想测试是不是中间人中间人攻击的时候又恢复访问了。

虽然有可能是服务器的问题，但实在是太巧合了，每次都是差不多时间段，都是用真实有效证书的节点没问题，自签的节点出现短暂超时。因为我以前假 ssl 验证的 frp 就经常会被阻断！（不过我暂时还没测试用真的 ssl 证书会不会改善）

我的想法是怀疑墙会不会在闲时自动对“不可靠”ssl 进行中间人攻击从而收集信息呢？

各位还有什么可以测试是不是闲时中间人攻击的思路推给我不。比较喜欢折腾研究，最近也刚好有空。

最后，感谢您读到这！

[ZE3kr]

看下服务器日志，是不是每天晚上定时自动重启了什么的

[qingmuhy0]

@ZE3kr 应该不是，如果是的话就不能解释为什么 lets 的签名站不会这样了，不过我也查了进程的信息，结果如下。

root@VM-4-4-ubuntu:~# ps -p 7268
PID TTY TIME CMD
7268 ? 00:00:02 nginx
root@VM-4-4-ubuntu:~# ps -p 7268 -o lstart
STARTED
Thu May 5 16:13:07 2022
root@VM-4-4-ubuntu:~# ps -p 611772
PID TTY TIME CMD
611772 ? 00:11:04 xray-linux-amd6
root@VM-4-4-ubuntu:~# ps -p 611772 -o lstart
STARTED
Mon May 9 14:11:28 2022
root@VM-4-4-ubuntu:~#

[ZE3kr]

@qingmuhy0 你说的 Lets Encrypt 站是普通的网站还是也是一模一样的 vmess ？这两种还是能识别出来的

[qingmuhy0]

@ZE3kr 一样都是代理节点，稍微有一点区别就是 letscrypt 的节点用的是 vless ，自签的则用的是 vmess 。

[qingmuhy0]

@ZE3kr
固定时间断流的：vmess+ws+自签苹果证书（安装了自己的 ca 证书，未开允许不安全）
正常的：vless+grpc+letscrypt 的证书。（自己的 com 域名申请的）

以上都是用的 X-ray 内核。

本来应该和上面信息合一起的，不小心按了回复。

[ThirdFlame]

127-0-0-1.nhost.00cdn.com 试试这个迅雷的白域名。

开头部分，你按照规则修改下 会发现解析会跟着变。 就可以申请证书了。

[yaott2020]

@ThirdFlame 那岂不是可以颁发合法证书了？

[ThirdFlame]

@yaott2020 #7 当然可以签发证书了。 这个域名 绝对白。

[whoops]

@ThirdFlame 这都被你发现了 太牛了

[Love4Taylor]

@ThirdFlame 当初 mcdn.bilivideo.cn 也是，但是后来就限制了。估计这个以后也会。

[zhengrt]

@ThirdFlame 太牛了 谢谢大佬

[ThirdFlame]

@Love4Taylor #10 是的 bilibili 的一开始也可以随意解析，后来只有 mcdn 节点上线后，解析才生效 ，
不过某雷这个，已经很久了。希望迅雷一直意识不到这个事儿。

[qingmuhy0]

@ThirdFlame 卧槽，这个流弊，已经用上了，既是真的，应该也会在白名单内。

[qingmuhy0]

说一下最终解决方案，用了上面大佬提供的 CDN 域名+GRPC+SSL ，配置了访问直接跳转迅雷官网。自我感觉挺完美的。

[dndx]

@ThirdFlame 这种申请可信证书了后都会显示在 Certificate Transparency 里： https://crt.sh/?q=nhost.00cdn.com 不介意的话的确可以用。

[zhengrt]

@dndx 今天申请了一堆 会不会被发现啊哈哈哈

[dndx]

@zhengrt
不介意服务器 IP 曝光就申请呗，只要申请了，记录就永远在那无法消除。就看个人能不能接受了。

[sbilly]

ip2100177547.funshion.com

[ThirdFlame]

@dndx #15 这个只要申请证书就有记录，关键是这个 ip 随着域名一起暴露 没办法了。 只是给大家借用白名单的思路

[ThirdFlame]

@sbilly #18 收藏了 以备不时之需

[swiftg]

有人试过 zerossl 的 ip 证书了吗，免费的，有效期三个月

[qingmuhy0]

@sbilly
@ThirdFlame
风行的这个域名是怎么弄的？有点好奇。

[takeshima]

你下次再碰到这个情况，改 host 把 apple.com 指向你的服务器，然后用浏览器访问你的网站试试

[jasonselin]

建议 x-ray 的 SS 开双向 ivcheck

[zanzhz1101]

@qingmuhy0
@sbilly 这个我试了我的 ip ，不行

[sadan9]

这个就算签了正式的证书，理论上安全性和自签差不多吧，或者更低点。毕竟域名的持有者理论上可以再签一个用于中间人。

[docx]

我也开了一个自签证书，暂时没发现断流什么的，楼主要不再看看？

[jsq2627]

细思极恐，要是真的对自签名证书搞中间人攻击，因为有很多人并不搭配自签 CA 使用，直接开了允许证书不安全，那就神不知鬼不觉地被嗅探了

[datocp]

哈哈完全不懂在说什么，看看专业的 stunnel 是怎么服务器端验证客户端证书再通讯，目前也仅会配置 level 2 。这个软件很多参数有些超前包括 qqmail 都不能支持 tls1.3

verify = LEVEL
verify the peer certificate

This option is obsolete and should be replaced with the verifyChain and verifyPeer options.

level 0
Request and ignore the peer certificate.

level 1
Verify the peer certificate if present.

level 2
Verify the peer certificate.

level 3
Verify the peer against a locally installed certificate.

level 4
Ignore the chain and only verify the peer certificate.

default
No verify.

verifyChain = yes | no
verify the peer certificate chain starting from the root CA

For server certificate verification it is essential to also require a specific certificate with checkHost or checkIP.

The self-signed root CA certificate needs to be stored either in the file specified with CAfile, or in the directory specified with CApath.

default: no

verifyPeer = yes | no
verify the peer certificate

The peer certificate needs to be stored either in the file specified with CAfile, or in the directory specified with CApath.

default: n

[sbilly]

@zanzhz1101 你咋试的？

[zanzhz1101]

@sbilly 搜一下 ip 如何转为数字

[wowawesome]

昨天用上面说的迅雷那个 CDN 绑定 IP, 今天被人 DDOS 了.
我这小鸡两年一直以来都没发生过这种事情, 不知道啥情况.

[gesse]

@wowawesome
有没有可能是用来 cdn 的域名，cdn 这个域名是用来给做种用户用的， 你解析了到了你服务器上，他们的 ns 服务器有记录，会让 p2p 用户通过域名来连你，形成了类似 DDOS 的情况？

[w18077112523]

无论如何都有找到 ipv4 地址的办法，全网扫描一次全都暴露，找个备案的服务器挺好的