开盘问题

历史抓包存下来的加密后的HTTPS流量，在服务端TLS证书私钥泄漏之后，内容是否可以被解密？

背景

密码体系

对称加密：加密和解密用到的密钥是相等的，比如AES加密算法。

非对称加密：由一对公钥、私钥组成，加密和解密用的密钥不同；通常公钥用于加密，私钥用于签名；由公钥加密的信息，只能由对应的私钥解开，由私钥进行的签名，可以用对应的公钥验证，主要用途为身份校验，如RSA算法。

私钥签名的例子：

单向陷门函数（one way trapdoor function)：已知x, 计算f(x)很简单，但是知道f(x)，却很难计算出x。

密钥交换（key exchange)

密钥交换（英语：Key exchange，也称key establishment）是密码学中两方交换密钥以允许使用某种加密算法的过程。

RSA key exchange

RSA算法：1977年，由Ron Rivest（美国），Adi Shamir（以色列），Leonard Adleman（美国）三位数学家创建。其安全性基于大整数（比如2048 bits）的因数分解非常困难。如 n = p * q，其中p和q都是非常大的整数，在仅知道n的情况下，没有快速的方法计算出p和q。举个简单的例子，直观体会一下2^2048有多大，目前可观测宇宙的原子数量为10^83（虽然不知道咋算出来的，姑且用了），进行一下log2运算，约为math.log2(10 ** 83) = 275.7200318756511，粗略算作 2^275，这样2^2048 / 2^275 = 2^1773。意味着，宇宙中的每个原子，需要平均存储比全部原子数还多的数字，才能把2^2048的数全部存下来，可以试想在没有特殊方法的情况下，在这一堆数字中找到p q两个数乘积为n的难度。

RSA计算过程以及证明可参考下列文章：

根据公钥密码体系的特点，公钥加密只能对应私钥解密，客户端可以用服务端的公钥（经过认证之后）将随机生成的密码加密后，再发送给服务端。由于这个密码只能由服务端解密，所以该密码只有通信双方知晓，后续双方可以使用该密码进行安全的通话。这是TLS1.3之前版本所支持的密钥交换算法之一。

?那么，使用RSA exchange有什么问题呢？这里，需要提到一个新的密码学概念。

前向安全（forward secrecy）

前向保密（英语：Forward Secrecy，FS）有时也被称为完全前向保密（英语：Perfect Forward Secrecy，PFS），是密码学中通讯协议的一种安全特性，指的是长期使用的主密钥泄漏不会导致过去的会话密钥泄漏。前向保密能够保护过去进行的通讯不受密码或密钥在未来暴露的威胁。[3]如果系统具有前向保密性，就可以保证在私钥泄露时历史通讯的安全，即使系统遭到主动攻击也是如此。

前向安全特性保护了过去（历史）的通信。

回到前面的RSA key exchange流程，很显然，如果有人有意地存下了历史的HTTPS会话，且服务端的私钥在未来泄密了，那么过去的通信内容也会被解密，从而不再安全。基于此原因，TLS1.3移除了全部无法提供前向安全的密钥交换算法。

另外，写该wiki的时候，发现一篇标题为SSL: Intercepted today, decrypted tomorrow的文章，很好地说明了前向安全的重要性，链接在此：SSL: Intercepted today, decrypted tomorrow | Netcraft News。

既然直接用RSA key exchange交换密钥无法提供前向安全，那应该如何安全地交换密钥呢？

Diffie-Hellman 密钥交换算法

DH算法由Whitfield Diffie（美国）与 Martin Hellman（美国）在1976年提出。2015年两人获得图灵奖。DH算法提供了一种在不安全通信信道下，安全地交换通信密码的途径。

?DH密钥交换流程如下：

?安全性保证：

但是，DH无法防范中间人攻击，如果存在监听者C，分别向A冒充B，向B冒充A，那么C就能与A、B进行DH密钥交换，双向传话，从而窃取信息了！

身份验证

上述DH过程，会遭到中间人攻击的原因在于A无法确认与其通信的确实是B本人，而身份证书可以解决该问题。TLS握手过程中，服务端会发送自己的证书给客户端，那么客户端是如何校验证书的有效性呢？

TLS证书链校验

证书颁发机构：

首先看一下证书结构，大致有证书签发机构、证书有效期、证书持有者、域名、证书公钥、签名（由证书颁发机构用私钥给颁发的证书签名，相当于担保，证明这张证书确实是由某个机构颁发）

签名过程：Signature = RSA(sha256(Data), IssuerPrivateKey)

证书链

以访问爱奇艺web页面为例，可以看到服务端发给浏览器的是一个证书链，其中最下面的就是爱奇艺的证书，GlobalSign RSA OV SSL CA 2018是一个中间层CA，最顶层的是GlobalSign，为Root CA，其公钥是自签名的，是信任的基础。

首先检查iqiyi证书，使用GlobalSign RSA OV SSL CA 2018公钥对iqiyi证书的签名进行校验，确保iqiyi证书确实是由其颁发，同时也会检查iqiyi证书的域名是否与我们访问的域名一致，证书是否在有效期内等信息；这一步无误之后，也会对GlobalSign RSA OV SSL CA 2018的证书进行同样的校验；最终会检查GlobalSign这个根证书。

那么问题来了，GlobalSign已经是自签名证书了，没有更上一级的机构给其背书，那我们如何确认这个GlobalSign确实真的是GlobalSign呢？

对于根证书机构的公钥，会内置在操作系统中，打开系统的key chain管理，可以找到同一个GlobalSign的证书，从而能完成整个证书链的校验。由于根证书是信任的起点，所以千万不可随意安装新的根证书到系统内！

Charles抓包HTTPS原理

由上述内容，不难看出Charles能抓取HTTPS流量的原理。在Charles能成功抓取HTTPS流量之前，用户必须操作的一步是手动将Charles的根证书导入到系统内，并且信任。当用户有这一步操作之后，其实就相当于信任了Charles所颁发的任意证书，从而Charles可以执行中间人攻击，伪装服务器，解析HTTPS流量。

在写wiki时，刚好发现公司的数据保护软件的一个例子，很好的说明了这种中间人攻击的情况。安装完公司的监控软件后，系统信任的证书里面出现了一个叫Endpoint Root CA的根证书，同时打开浏览器访问HTTPS网站，看到网站的证书已经变成了由Endpoint Root CA签发的证书，说明软件Endpoint已经在实施中间人攻击了。可以对比一下安装了Endpoint软件和没有安全Endpoint软件的浏览器访问相同网站时拿到的证书信息。

左为安装Endpoint之后；右为未安装Endpoint；可以看到两个状态下，baidu的证书已经完全不是同一张了。

SSL Pinning如何阻止抓包

在实际抓包过程中会发现有些APP的HTTPS流量无法抓到，有一部分原因是APP使用了SSL Pinning技术。在启用SSL pinning之前，APP默认是对系统内的Root CA颁发的证书无条件信任，所以Charles能成功伪装成服务端，执行中间人攻击。而SSL Pinning则是APP打包的时候，将服务端的证书一起打包进安装包，除了常规的证书链检查，APP还会额外校验服务端返回的证书是否和本地的证书一致，如果不一致，将会断开请求。