这是一个创建于 1243 天前的主题，其中的信息可能已经有所发展或是发生改变。
先说一下我的情况吧，我是 vmess 的 ws 传输模式，服务端用的自签名的 apple.com 证书，手机上安装了对应的 CA 证书，因此出于安全原因，我没有开允许证书不安全。
然后是我碰到的怪事，白天使用的时候一直都是正常的，但只要一到晚上两三点就会出现自己域名真实有效的 ssl 证书反代的 ws 可以连接，自签的节点出现超时问题，每次我立马想测试是不是中间人中间人攻击的时候恢复访问了。
虽然有可能是服务器的问题，但实在是太巧合了，每次都是差不多时间段，都是用真实有效证书的节点没问题，自签的节点出现短暂超时。因为我以前假 ssl 验证的 frp 就经常会被阻断！（不过我暂时还没测试用真的 ssl 证书会不会改善）
我的想法是怀疑墙会不会在闲时自动对“不可靠”ssl 进行中间人攻击从而收集信息呢？
各位还有什么可以测试是不是闲时中间人攻击的思路推给我不。比较喜欢折腾研究，最近也刚好有空。
最后，感谢您读到这！
 | 1 ZE3kr 2022-05-16 02:59:30 +08:00 via iPhone 看下服务器日志，是不是每天晚上定时自动重启了什么的 |
 | 2 qingmuhy0 OP @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:~# |
| 4 qingmuhy0 OP @ZE3kr 一样都是代理节点，稍微有一点区别就是 letscrypt 的节点用的是 vless ，自签的则用的是 vmess 。 |
| 5 qingmuhy0 OP @ZE3kr 固定时间断流的：vmess+ws+自签苹果证书（安装了自己的 ca 证书，未开允许不安全） 正常的：vless+grpc+letscrypt 的证书。（自己的 com 域名申请的） 以上都是用的 X-ray 内核。 本来应该和上面信息合一起的，不小心按了回复。 |
 | 6 ThirdFlame 2022-05-16 09:12:28 +08:00  15 |
 | 7 yaott2020 2022-05-16 09:24:37 +08:00 via Android @ThirdFlame 那岂不是可以颁发合法证书了？ |
| 8 ThirdFlame 2022-05-16 09:50:49 +08:00 @yaott2020 #7 当然可以签发证书了。 这个域名 绝对白。 |
 | 9 whoops 2022-05-16 10:43:33 +08:00 via iPhone @ThirdFlame 这都被你发现了 太牛了 |
 | 10 love4taylor PRO @ThirdFlame 当初 mcdn.bilivideo.cn 也是，但是后来就限制了。估计这个以后也会。 |
 | 11 zhengrt 2022-05-16 10:55:33 +08:00 @ThirdFlame 太牛了 谢谢大佬 |
| 12 ThirdFlame 2022-05-16 10:58:07 +08:00 @Love4Taylor #10 是的 bilibili 的一开始也可以随意解析，后来只有 mcdn 节点上线后，解析才生效 ， 不过某雷这个，已经很久了。希望迅雷一直意识不到这个事儿。 |
| 13 qingmuhy0 OP @ThirdFlame 卧槽，这个流弊，已经用上了，既是真的，应该也会在白名单内。 |
| 14 qingmuhy0 OP 说一下最终解决方案，用了上面大佬提供的 CDN 域名+GRPC+SSL ，配置了访问直接跳转迅雷官网。自我感觉挺完美的。 |
 | 15 dndx 2022-05-16 14:46:05 +08:00 1 @ThirdFlame 这种申请可信证书了后都会显示在 Certificate Transparency 里： https://crt.sh/?q=nhost.00cdn.com 不介意的话的确可以用。 |
 | 18 sbilly 2022-05-16 17:40:56 +08:00 |
| 19 ThirdFlame 2022-05-16 18:33:02 +08:00 @dndx #15 这个只要申请证书就有记录，关键是这个 ip 随着域名一起暴露 没办法了。 只是给大家借用白名单的思路 |
| 20 ThirdFlame 2022-05-16 18:38:22 +08:00 @sbilly #18 收藏了 以备不时之需 |
 | 21 swiftg 2022-05-16 18:40:29 +08:00 via iPhone 有人试过 zerossl 的 ip 证书了吗，免费的，有效期三个月 |
| 22 qingmuhy0 OP |
 | 24 jasonselin 2022-05-16 19:40:04 +08:00 建议 x-ray 的 SS 开双向 ivcheck |
 | 25 zanzhz1101 2022-05-16 19:45:55 +08:00 |
 | 26 sadan9 2022-05-16 20:03:06 +08:00 via iPhone 这个就算签了正式的证书，理论上安全性和自签差不多吧，或者更低点。毕竟域名的持有者理论上可以再签一个用于中间人。 |
 | 27 docx 2022-05-16 20:42:33 +08:00 via iPhone 我也开了一个自签证书，暂时没发现断流什么的，楼主要不再看看？ |
 | 28 jsq2627 2022-05-16 22:50:20 +08:00 细思极恐，要是真的对自签名证书搞中间人攻击，因为有很多人并不搭配自签 CA 使用，直接开了允许证书不安全，那就神不知鬼不觉地被嗅探了 |
 | 29 datocp 2022-05-17 06:23:41 +08:00 via Android 哈哈完全不懂在说什么，看看专业的 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 |
| 30 sbilly 2022-05-17 08:35:50 +08:00 @zanzhz1101 你咋试的？ |
| 31 zanzhz1101 2022-05-17 08:37:40 +08:00 @sbilly 搜一下 ip 如何转为数字 |
 | 32 wowawesome 2022-05-18 15:36:06 +08:00 昨天用上面说的迅雷那个 CDN 绑定 IP, 今天被人 DDOS 了. 我这小鸡两年一直以来都没发生过这种事情, 不知道啥情况. |
 | 33 gesse 2022-05-18 22:56:43 +08:00 @wowawesome 有没有可能是用来 cdn 的域名，cdn 这个域名是用来给做种用户用的， 你解析了到了你服务器上，他们的 ns 服务器有记录，会让 p2p 用户通过域名来连你，形成了类似 DDOS 的情况？ |
 | 34 w18077112523 2022-05-29 13:06:46 +08:00 无论如何都有找到 ipv4 地址的办法，全网扫描一次全都暴露，找个备案的服务器挺好的 |
Select Language