项目开源了，感兴趣的可以为二次元贡献一颗star
https://github.com/COLOR-SKY/ID-INVADED-WINDOWED
消息来源: https://t.me/ijustseesee/4723
https://github.com/COLOR-SKY/ID-INVADED-WINDOWED
消息来源: https://t.me/ijustseesee/4723
GitHub
GitHub - COLOR-SKY/ID-INVADED-WINDOWED: Source code of my project ID:INVADED(WINDOWED)
Source code of my project ID:INVADED(WINDOWED). Contribute to COLOR-SKY/ID-INVADED-WINDOWED development by creating an account on GitHub.
安利一个魔鬼开学频道 @nCoV_Term_Begin
从上图中可以看到，该证书的影响不仅仅在github，实际上范围非常大。通过DNSMon系统，我们提取出了受影响的域名共14655个。
在二级域方面， github.io 是受影响最大的二级域，也是此次劫持事件的关注焦点。
通过DNSMon系统查看这些域名的流行度，在TOP1000的域名中，有40个域名受影响，列表如下：
1 www.jd.com
5 www.baidu.com
10 www.google.com
37 www.sina.com
44 www.163.com
51 www.douyu.com
62 www.suning.com
86 www.pconline.com.cn
91 sp1.baidu.com
126 twitter.com
137 www.eastmoney.com
143 mini.eastday.com
158 sp0.baidu.com
174 www.jianshu.com
177 www.mgtv.com
185 www.zhihu.com
232 www.toutiao.com
241 price.pcauto.com.cn
271 www.google.com.hk
272 video.sina.com.cn
299 www.youtube.com
302 www.acfun.cn
365 www.vip.com
421 news.ifeng.com
451 car.autohome.com.cn
472 www.facebook.com
538 www.gamersky.com
550 www.xiaohongshu.com
552 www.zaobao.com
580 www.xxsy.net
621 www.huya.com
640 mp.toutiao.com
643 www.ifeng.com
689 www.ip138.com
741 dl.pconline.com.cn
742 v.ifeng.com
784 www.yicai.com
957 passport2.chaoxing.com
963 3g.163.com
989 www.doyo.cn
对这些域名发生证书劫持时的DNS解析情况分析发现，这些域名的解析IP均在境外，属于这些域名在境外的CDN服务。值得一提的是尽管这些域名都是排名靠前的大站，但是因为国内访问的时候，CDN解析会将其映射为国内的IP地址，因此国内感知到这些大站被劫持的情况比较小。在二级域方面， github.io 是受影响最大的二级域，也是此次劫持事件的关注焦点。
1297 github.io
35 app2.xin
25 github.com
18 aliyuncs.com
17 app2.cn
14 nnqp.vip
10 jov.cn
8 pragmaticplay.net
7 tpdz10.monster
7 suning.comhttps://blog.netlab.360.com/ongoing-websites-hijacking/
消息来源: https://t.me/ak1ra_ch/1247
消息来源: https://t.me/ak1ra_ch/1247
360 Netlab Blog - Network Security Research Lab at 360
一些网站https证书出现问题的情况分析
[20200328 17:00 更新] 更新数据到20200328 16:00.
20200326下午，有消息说[1]github的TLS证书出现了错误告警。证书的结构很奇怪，在其签发者信息中有一个奇怪的email地址：346608453@qq.com。明显是一个伪造的证书。
为了弄清楚其中的情况，我们对这一事件进行了分析。
DNS劫持？
出现证书和域名不匹配的最常见的一种情况是DNS劫持，即所访问域名的IP地址和真实建立连接的IP并不相同。
以被劫持的域名go-acme.github.io…
20200326下午，有消息说[1]github的TLS证书出现了错误告警。证书的结构很奇怪，在其签发者信息中有一个奇怪的email地址：346608453@qq.com。明显是一个伪造的证书。
为了弄清楚其中的情况，我们对这一事件进行了分析。
DNS劫持？
出现证书和域名不匹配的最常见的一种情况是DNS劫持，即所访问域名的IP地址和真实建立连接的IP并不相同。
以被劫持的域名go-acme.github.io…
TL;DR trojan 用户请开启配置中的 verify 和 verify_hostname。
根据 trojan 的工作原理，只要开启了 config.ssl.verify 和 config.ssl.verify_hostname，就不会受到 MITM 攻击，也不会泄露出客户端正在使用 trojan 翻墙。所以建议大家尽快为服务器配置证书，可以使用提供免费证书的 acme.sh 和 certbot。
未开启 verify 和 verify_hostname 的客户端，如果遭到 GFW 的 MITM 攻击，GFW 将可能尝试使用 trojan 协议规定的数据包格式来解析你的请求。如果解析成功，说明你在 TLS 中传输的不是 HTTP 请求——换言之，说明你在使用 trojan 翻墙。同时，GFW 也可以得知你所访问的服务器 ip 正提供基于 trojan 的翻墙服务，进而有针对性地封禁服务器。
更进一步地，GFW 如果对 trojan 代码进行修改，使其在作为 server 工作时允许所有 trojan client 连接，那么将可以获得所有未开启 verify 和 verify_hostname 的客户端的请求明文，且客户端不会请求失败。这非常简单，只需要将 https://github.com/trojan-gfw/trojan/blob/master/src/session/serversession.cpp#L141 这一行修改为 if(false) { 即可。在此基础上，GFW 将可以在 TLS MITM 攻击的基础上，发起 trojan MITM 攻击，使得未开启 verify 和 verify_hostname 的 trojan 客户端在无感知的情况下被 GFW 获得请求与应答。
旧：trojan client —> trojan server —> website —> trojan server —> client
新：trojan client —> GFW trojan server (MITM) —> actual trojan server —> website —> actual trojan server —> GFW trojan server (MITM) —> trojan client
开启了 verify 和 verify_hostname 的客户端将不会被 MITM 攻击。
（不用担心你设定的 trojan 密码被知道（即使是没有开启 verify 和 verify_hostname）。这是因为 trojan 在传输密码时只传输其哈希值（详见 https://trojan-gfw.github.io/trojan/protocol 和 https://github.com/trojan-gfw/trojan/blob/master/src/core/config.cpp#L65 ）。）
结论：至少根据咱的分析，这是完全可行的攻击思路。所以，趁着他们还没有这么做，赶紧去给自己的 trojan server 加上证书。以 trojan 的用户规模，可能在 GFW 那里的优先级不算很高，应该还来得及。
消息来源: https://t.me/melon_murmur/333
根据 trojan 的工作原理，只要开启了 config.ssl.verify 和 config.ssl.verify_hostname，就不会受到 MITM 攻击，也不会泄露出客户端正在使用 trojan 翻墙。所以建议大家尽快为服务器配置证书，可以使用提供免费证书的 acme.sh 和 certbot。
未开启 verify 和 verify_hostname 的客户端，如果遭到 GFW 的 MITM 攻击，GFW 将可能尝试使用 trojan 协议规定的数据包格式来解析你的请求。如果解析成功，说明你在 TLS 中传输的不是 HTTP 请求——换言之，说明你在使用 trojan 翻墙。同时，GFW 也可以得知你所访问的服务器 ip 正提供基于 trojan 的翻墙服务，进而有针对性地封禁服务器。
更进一步地，GFW 如果对 trojan 代码进行修改，使其在作为 server 工作时允许所有 trojan client 连接，那么将可以获得所有未开启 verify 和 verify_hostname 的客户端的请求明文，且客户端不会请求失败。这非常简单，只需要将 https://github.com/trojan-gfw/trojan/blob/master/src/session/serversession.cpp#L141 这一行修改为 if(false) { 即可。在此基础上，GFW 将可以在 TLS MITM 攻击的基础上，发起 trojan MITM 攻击，使得未开启 verify 和 verify_hostname 的 trojan 客户端在无感知的情况下被 GFW 获得请求与应答。
旧：trojan client —> trojan server —> website —> trojan server —> client
新：trojan client —> GFW trojan server (MITM) —> actual trojan server —> website —> actual trojan server —> GFW trojan server (MITM) —> trojan client
开启了 verify 和 verify_hostname 的客户端将不会被 MITM 攻击。
（不用担心你设定的 trojan 密码被知道（即使是没有开启 verify 和 verify_hostname）。这是因为 trojan 在传输密码时只传输其哈希值（详见 https://trojan-gfw.github.io/trojan/protocol 和 https://github.com/trojan-gfw/trojan/blob/master/src/core/config.cpp#L65 ）。）
结论：至少根据咱的分析，这是完全可行的攻击思路。所以，趁着他们还没有这么做，赶紧去给自己的 trojan server 加上证书。以 trojan 的用户规模，可能在 GFW 那里的优先级不算很高，应该还来得及。
消息来源: https://t.me/melon_murmur/333
GitHub
trojan/src/session/serversession.cpp at master · trojan-gfw/trojan
An unidentifiable mechanism that helps you bypass GFW. - trojan-gfw/trojan
🤔 劫持规模进一步扩大, 大量合法站点亦被劫持
包括一些CDN回源时也会受到影响, 看不懂诶
目前知道的消息:
- 针对443端口的L4劫持
- 在中间路由对443直接返回, mtr其他端口均正常
- 做的似乎不是很好, 抓包下来6个包能有四种TTL(来源)
- 可能是针对 Naive/Trojan 等SSL隧道, Naive 直接没有证书验证, 很容易被抓到数据, 需要尽早防范
消息来源: https://t.me/berd_channel/894
包括一些CDN回源时也会受到影响, 看不懂诶
目前知道的消息:
- 针对443端口的L4劫持
- 在中间路由对443直接返回, mtr其他端口均正常
- 做的似乎不是很好, 抓包下来6个包能有四种TTL(来源)
- 可能是针对 Naive/Trojan 等SSL隧道, Naive 直接没有证书验证, 很容易被抓到数据, 需要尽早防范
消息来源: https://t.me/berd_channel/894
