今天饭前，博主的小伙伴突然发来 QQ 消息，说发现用 HTTPS 访问新浪微博的图片时出现证书错误的警告，并且证书是12306的证书。
博主看后吓了一跳，难道说新浪被中间人了？但是一想，新浪开启了 HTTPS 么？不过经过博主的测试，发现确实是这么一回事。
这下 12306 这么屌？竟然敢这么正大光明地中间人了？也不怕广大人民群众嫩死它？真不愧博主提早把 12306 的证书给设置为不信任了…
博主用 HTTPS 打开了好几个 sinaimg 的地址，发现所有地址浏览器都会出现证书警告，但是有些证书是 12306 的，有些又是由 all 颁发给 all 的自签名证书（嘛，12306 也是自签名的证书）。然后博主想了想，百撕不得骑姐，然后就愉快地吃饭去了= =
吃完饭回来，博主还是没有多想，就去欢乐地玩以撒去了╮(￣▽￣)╭ 玩了半个小时，博主突然领悟出可能出现上述情况的原因。
Σ( ￣□￣||)你玩个游戏想这么多干嘛
博主首先使用 ping 命令，ping 了下 12306 的网址，之后又 ping 了下 sinaimg.cn 的网址，虽然他们 IP 不一样，但是——它们用了同一个 CDN 供应商的服务。对于那些没有返回 12306 证书的二级域名，例如 tp2.sinaimg.cn，它就不是用的网宿科技的 CDN 服务。
这下博主有 90% 的把握确定就是博主想的原因了。先去查了查 whois 信息，看 lxdns.com 是哪家 CDN 供应商的域名，然后发现，是网宿科技的域名。
之后，博主又去站长工具查了查同IP网站查询，输入 12306.xdwscache.glb0.lxdns.com，点击查询…..哇塞，足足有 1600 多个域名，这网宿好牛逼啊，国内各个大型互联网公司都有域名在使用它的 CDN 服务。像新浪，网易，4399，乐视，12306，腾讯等等…
之后，随便打开几个列表中的网址，使用 HTTPS 访问，果不其然，出现了下面的情况，清一色的 12306 证书
接下来博主要开始推测了，只是推测，如果有误，请指正。
SSL 协议层是在 HTTP 协议层下面的，当 SSL 连接建立时，SSL 模块在 Web 模块之前和浏览器进行通讯并交换证书、建立加密隧道。众所周知，Web 服务器是通过 HTTP 数据包中的 Host 字段来区分虚拟主机的，而 SSL 模块在把服务器证书发送到浏览器时，还没有收到任何关于 HTTP 的数据包，更不知道虚拟主机的域名，因此 SSL 模块只能固定的将一张 SSL 证书发送到浏览器，而不能根据域名有选择性的发送证书。
可以推倒出，在使用 HTTPS 访问上述网址时，SSL 模块与 CDN 供应商建立连接，但是 CDN 供应商并不知道我们请求的 Host 是哪个，于是只好返回第一张 SSL 证书给浏览器。看起来网宿科技使用的是通常的在前面加 N 级域名的形式来区分 Host 的，12306 因为它为数字，并且第三位的 3 比 6 小，所以就返回了 12306 的证书，不然如果 126 购买了 HTTPS 服务，就会返回 126 的证书了，当然，如果有一个 121，可能返回的就是 121 的证书了。
不过，用 SNI 技术就可以在同 IP 同端口的服务器上返回正确的证书，说白了也就是在建立 SSL 连接时，就发送了 Host 信息，使得 SSL 模块可以正确发送相应的证书。这个在 SSLv3 以及 TLS 都是支持的。
所以这情况只好猜测是网宿科技可以正确返回购买了 HTTPS 服务的域名的 SSL 证书，但是对于没有设置证书的域名，SSL 模块自动返回了第一个证书，恰巧它就是 12306。
博主表示不明觉厉(´･_･`)前面的都是我编的，你们不要打我
不过，12306 这次可真是当了冤大头咯- –
有什么不对的，请轻拍( · 8 · )biu
原创文章，转载请以链接形式注明出处：https://blog.ttionya.com/article-959.html