回目录 《github系列网络事件解析》
# 20200325 github https证书问题
关键词：https劫持、ssl劫持、dns劫持
# 来源
Github pages 的 HTTPS 是不是出问题了？ (opens new window) Cloudflare 的一个节点疑似也被中间人 (opens new window) 京东 HTTPS 也被劫持了？ (opens new window)
# 基础说明
首先我根据自己的理解说明下，所谓gtihub page https劫持并不是说劫持了github page，而是在访问者和githubpage的沟通链路上插入了自己的监听点； 本质上跟自己电脑上装个抓包工具，设置代理的逻辑没有任何区别，再比如如果是针对某台机器的劫持，比如对局域网内张三的电脑流量劫持， 就只需要在这个局域网内搞一下，比如在张三电脑上装个angent，或者在路由器上搞点动作；再进一步，如果对某个地区的网络全面监听，就需要具备更厉害的本事， 可以在骨干网络上搞破坏；
另外github page的用户默认用的是二级域名，比如我的是 https://lyhistory.github.io ，这个域名是github的，所以dns也是github自己配的，与我无关， 所以劫持者如果是针对github page就可以对其dns链路上搞破坏；然后我配置了自己的独立域名，https://lyhistory.com，而且我自己在域名注册商那里改了默认的dns解析， 用了cloudflare，刚开始我以为我的https cert是github自己颁发的，结果是cloudflare颁发的（我忘记在更换dns之前查看cert是谁颁发的了， 不过我查了下在配置自己的独立域名之前，cert确实是github自己的，是DigiCert颁发给github的，所以用默认的二级域名是一个cert，我猜测用独立域名的注册商默认的dns解析是一个cert， 换dns解析后期我确定也换到了dns解析者的cert，后面也截图）
我感觉到很奇怪，所以查了下，才知道cloudflare ssl加密有三种模式
这是我当时切换后的截图：
所以如果中间人想搞破坏我觉着有这么直观的几种思路：
1）一个是在cloudfalre的dns解析上搞破坏，这个需要大规模的破坏cloudflare的cdn网络，有点难度，除非你懂的；
2）一个是在解析之后去往github page的链路上搞破坏，这个更难了，因为前者至少还有部分用户会设置相信非法cert，但是我相信cloudflare不会这么轻易相信中间人的cert，这个可以排除；
# 引用分析
好了，开始说这起事件，因为人在海外，不方便测试，就总结了网友的测试分析结果如下（引用的推特地址在文末）：
国内访问提示证书错误，SSL劫持？
目前许多翻墙软件是基于（或伪装成）TLS(HTTPS)的，以v2ray(N)为例，若部署服务端的时候没有使用有效的证书，客户端启用了allowInsecure的情况下（默认），若被中间人攻击了客户端可能也无法进行警告。
我的评论：未必吧，不可以配置客户端信任自己的证书吗，这样不就可以挡住其他的非法证书了么（当然了这个需要再研究下）
不过正确配置了加密方式的情况下，数据还是安全的，只是攻击者可能会知道你在用v2ray。
我的评论：刚开始看到这句话觉着有问题，如果选择相信中间人的证书，中间人就完全可以解密流量，不过细想下，v2ray是伪装成https流量，其本身也是有加密的， 所以应该指的是解密开的流量本身仍然是v2ray加密内容，直到走到我们配置的vpn服务器端，然后vpn服务器端才能解密开流量，除非中间人在vpn服务器和我们的目标之间劫持； https只是信道加密，接收端可以解密，所以应该还需要采取对敏感内容的加密，不能仅仅依赖信道加密；
这是网友从国内测试正常恢复之后的tcproute：
我对图上的cert有点好奇，为啥到6月就过期，所以看看我自己的
可以看到因为我最近前两天刚换成了cloudflare的dns解析，也是到6月，可能人家就是这么短期的cert，然后不断更新，但是显示的cert是cloudflare颁发的，不过我有点好奇的是，我以为只是dns解析交给cloudflare，
但是https cert是github page自己的呢，这个不是很熟悉，以后再研究下 这个已经搞清楚了，前面补充解释了cloudflare的ssl加密模式
然后我对网友的tcproute结果不太明白，所以自己验证了下
tcproute -p 443 github.io
果然github.io是同一个ip网段，不过我有点不明白的是，中间人如果劫持了，一样可以放行流量到达github page，tcp route里面从哪看出来这里没有中间人呢？ 还是说如果有中间人tcproute的内容会不同，我看了下网友提供的他认为是劫持的tcproute截图，不同点是remote ip也就是终点是不同的ip段，我才想起来， 我们这里是指定了443端口的请求，中间人劫持的正是443，可能tcproute用的这个协议本身（是IMCP?)并不存在流量放行的问题，谁劫持的就到他那里， 如果是用浏览器打开目标网站，劫持者的cert是非法的，浏览器会提示危险，但是如果我们手动或者电脑设置自动放行，会拿到劫持者的cert， 但是http流量到中间人那里肯定是会放行通过的，毕竟中间人的目的不是阻塞流量，而是在中间监听流量，所以我猜应该是因为如此，所以从tcproute 443的终点就能看出来是否被劫持， 终点也自然是劫持者的位置；
补充：
其实现在很多服务商都启动了DDos防护，所以tcproute有时候可能会触发正常的BGP FlowSpec，所以分析的时候也是要注意，不要与流量劫持混淆；
关于dns lookup的非权威应答问题
C:\Users\lyhis\Downloads\tcproute>nslookup github.com
DNS request timed out.
timeout was 2 seconds.
Server: UnKnown
Address: 2406:3003:2006:3858:26f5:a2ff:fe56:5326
DNS request timed out.
timeout was 2 seconds.
Non-authoritative answer:
Name: github.com
Address: 13.250.177.223
解释： From Wireshark Lab: DNS v6.01: However, nslookup also indicates that the answer is “non-authoritative,” meaning that this answer came from the cache of some server rather than from an authoritative MIT DNS server
# more
内心并不期待发生更多事情....
主要参考：
https://twitter.com/FledgeXu/status/1243073941138096129
https://twitter.com/chenshaoju/status/1243078679380426753