回目录 《github系列网络事件解析》

# 20200325 github https证书问题

关键词:https劫持、ssl劫持、dns劫持

# 来源

Github pages 的 HTTPS 是不是出问题了? Cloudflare 的一个节点疑似也被中间人 京东 HTTPS 也被劫持了?

# 基础说明

首先我根据自己的理解说明下,所谓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

Github 中间人攻击原理分析

HTTPS中间人攻击实践(原理·实践)