解析 SSL Inspection＆Certificate-pinning

SSL是一种被广泛用于实现安全通信的协议，自Netscape在1995年发布SSL v2.0(v1.0因其瑕疵未曾发布)到现在的TLS v1.3(TLS是SSL的继任者，https://tools.ietf.org/html/rfc8446)已经过去了20多年，对SSL最为熟知的应用就是HTTPS (HTTP over SSL)。如今想要找一个non-https的网站并不那么容易，NSS Labs预测到2019年之前，将有75%的Web流量是经过加密的。这是好事，Internet通信更安全了，不过也产生了一些新的问题：

攻击者利用加密信道隐藏攻击代码，例如在HTTPS流量中嵌入恶意代码

攻击者利用加密信道转移盗取的信息

传统安全过滤解决方案对于加密流量不可见，形同虚设

user-based logging不再有效

无法做SSL sites debugging

....等等

好在现在大部分的安全解决方案都拥有SSL Inspection的能力， 获取了对加密流量的可见性。

SSL Inspection 是如何工作的？

SSL Inspection的本质在于引入了中间人(man-in-the-middle, MITM)，在通信双方之间实施了消息截获、角色扮演(impersonate)的行为，目的就是为了可视化加密流量。简单来说，中间人与用户建立了一条SSL tunnel，同时也与用户需要访问的服务器建立了另一条SSL tunnel，因此通信依然是安全的，只是双方的通信内容对于中间人是可见的，实现对通信内容的控制。

SSL Inspection workflow

用户browser访问一个HTTPS站点。

中间人截获该HTTPS请求，自己与目标服务器建立一个单独的SSL隧道。

目标服务器向中间人发送其自己的证书（serverHello Msg）。

目标服务器和中间人完成SSL handshake，双方开始发送 Application Data。

中间人与用户的浏览器建立SSL negotiation，同时将自己的root certificate以及服务器证书（经过中间人的root CA 签名）发送给 user browser。user browser 通过certificate store来验证certificate chain。

Charles proxy和browser完成SSL handshake，并开始发送 Application Data。

图一：SSL Inspection workflow

注：图一引自Zscaler。

利用Charles Proxy 演示 SSL Inspection

SSL Proxy是一种典型的拥有SSL Inspection能力的软件，比如Charles Proxy。我将采用Charles Proxy 演示 SSL Inspection，用于观察加密流量。

环境非常简单，client Charles Proxy Web server。我的 client是一台 iOS 12.1.1 iPhone XR，在 Wi-Fi interface中设置了Charles proxy，然后随意访问一个HTTPS站点，比如www.bing.com。通过trace Charles proxy的Wi-Fi 接口，能够看到完整的 SSL Negotiation (clientHello -> serverHello -> key exchange -> change cipher spec -> began to transfer App data)，但是SSL隧道建立完成后，所有的流量都是加密的，即这里的Encrypted Application Data。

随后在搜索栏中键入关键字 iron man执行搜索，结果如下图：

图三：搜索iron man的结果

此时，在packet trace中，依然只能看到Application data，但Charles Proxy已经能够通过其自己的搜索模块搜索到iron man字符串，并且访问的内容会被整合在左侧栏。可见，Charles Proxy已经在扮演中间人的角色。

图三：Charles Proxy 能够观察到搜索内容

服务器证书替换行为

iPhone在访问Bing的时候会收到来自服务器的证书，该证书的commonName就是URL www.bing.com，信任链结构如下：

访问www.bing.com之所以不会收到任何安全警告信息，是因为iOS certificate store已经集成了Baltimore CyberTrust Root根证书，可以顺利的验证整个信任链，最终信任www.bing.com这张服务器证书。macOS Mojave的System Roots也有这张证书。见：https://support.apple.com/en-us/HT209144

图5：macOS Mojave System Roots

可问题是，作为中间人的Charles proxy并不能直接将www.bing.com服务器证书转发给iPhone，因为Charles proxy无法使用www.bing.com的服务器证书与iPhone建立SSL连接，根本原因是Charles proxy没有www.bing.com的private key。所以，实际情况是，Charles proxy复制了ww.bing.com证书的Subjects等其它公共信息，然后用自己生成Charles root根证书重新sign了一张服务器证书用于同iPhone建立SSL tunnel。因此，在iPhone看来，自己收到的服务器证书虽然commonName == www.bing.com，但其签发者已经变成了Charles root。由于Charles root根证书默认不在iOS certifiate store，无法完整信任链验证，你会看到Safari发出警告信息。想要避免这个警告，可以下载并安装Charles root根证书并信任它。

图6：Safari警告信息

点击 Show Details -> View Certificate可以清楚的看到着这样由Charles proxy发送过来的证书的内容，其签发者已经变成了 Charles Proxy CA。还可以看到其它一些有趣的信息，比如组织 == XK72 Ltd、State == Auckland、Country == NZ。有心的读者一定猜到了这可能与Charles Proxy的开发者相关。确实，Google一下你会发现作者就是来自新西兰的Karl von Randow，https://twitter.com/avon。

图7：由Charles Proxy 签发的服务器证书

这个证书替换的行为，在packet trace中也能验证，这是一个没有设置Charles proxy时访问AppStore时的抓包截图，可以看到，itunes.apple.com的签发者是DigiCert。

图8：没有SSL Inspection时访问AppStore时的服务器证书

而启用Charles proxy的SSL Inspection后，签发者就被前换成了Charles Proxy Root Certificate。

图9：启用SSL Inspection时访问AppStore时的服务器证书

参考

https://help.zscaler.com/zia/about-ssl-inspection

https://www.charlesproxy.com/documentation/configuration/proxy-settings/

https://www.nsslabs.com/company/news/press-releases/nss-labs-predicts-75-of-web-traffic-will-be-encrypted-by-2019/

https://www.positivessl.com/avoid-google-chrome-not-secure-warning

缩写

SSL (Secure Sockets Layer)

TLS (Transport Layer Security)

MIMT (Man-in-the-middle)