一些网站https证书出现问题的情况分析

2020.03.26下午，有消息说[1]github的TLS证书出现了错误告警。证书的结构很奇怪，在其签发者信息中有一个奇怪的email地址：[email protected]。明显是一个伪造的证书。

为了弄清楚其中的情况，我们对这一事件进行了分析。

[[320525]]

DNS劫持?

出现证书和域名不匹配的最常见的一种情况是DNS劫持，即所访问域名的IP地址和真实建立连接的IP并不相同。

以被劫持的域名go-acme.github.io为例，我们的passiveDNS库中该域名的IP地址主要使用如下四个托管在fastly上的IP地址，可以看到其数据非常干净。

对该域名直接进行连接测试，可以看到，TCP连接的目的地址正是185.199.111.153，但其返回的证书却是错误的证书。因此github证书错误的问题并不是在DNS层面出现问题。

劫持如何发生的?

为了搞清楚这个问题，可以通过抓取链路上的数据包来进行分析。为了有较好的对比性，我们先后抓取了443端口和80端口的数据。如下图

TCP三次握手中的服务器应答对比

左边的数据包为https连接，右边的数据包为http连接。可以看到https的服务器应答TTL为53，http的则为44。一般来说，在时间接近的情况下，连接相同的目标IP，数据包在链路上的路径是是近似的。https的TTL显著的大于http的TTL，看起来很有可能是在链路上存在劫持。

有意思的是在https后续的连接中其TTL值并不稳定，比如在响应证书的数据包中，其TTL变成了47，介于44和53之间，更接近于http链路的情况。作为对比，http的后续数据包的TTL值则一直稳定在44。

[20200327 23:00 更新] 在数据包内容方面，另一个值得关注的点是：被劫持的会话数据包(https)全部回包的IPID都是0. 正常数据包(http)首次回包IPID是0，之后的回包就不是了。

这是两个有意思的现象。

被劫持会话后续返回的TTL值

因此，结合https会话过程中TTL值和IPID的异常，我们猜测是在链路上发生了劫持。

证书是怎么回事?

事实上，从我们DNSMon系统的证书信息来看，这个证书(9e0d4d8b078d7df0da18efc23517911447b5ee8c)的入库时间在20200323早上六点。考虑到数据分析的时延，其开始在大网上使用最晚可以追溯到20200322。

同时可以看到，这个证书在证书链上的父证书(03346f4c61e7b5120e5db4a7bbbf1a3558358562)是一个自签名的证书，并且两者使用相同的签发者信息。