解析 SSL Inspection

v1.0 - 首次发布 - 2018/12/26

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流量是经过加密的(见文章结尾Ref#3)。这是好事，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的工作流大致如下：

用户browser访问一个HTTPS站点。

中间人截获该HTTPS请求，自己去同用户要访问的目标服务器建立一个单独的SSL tunnel。

目标服务器向中间人发送其自己的证书（serverHello Msg，这是SSL/TLS handshake protocol 定义的）。

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

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

中间人和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根证书，可以顺利的验证整个信任链。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发出警告信息。（若想避免这个警告，可以为iOS下载并安装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中也能得到验证，图8是一个没有设置Charles proxy SSL Inspection时访问AppStore时的抓包截图，可以看到，itunes.apple.com的签发者是DigiCert。

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

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

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

但要注意的是，SSL Inspection不能很好的与Certificate-Pinning协作，AppStore就是这种支持Certificate-pinning的App，无法在启用SSL Inspection的情况下正常工作。Certificate-pinning的工作机理会在以后的文章中解析。

参考

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)