CDN私钥保护与HTTPS加速如何兼得？

  ▌什么是证书/私钥?

在数字化的网络世界中，证书是一个人或者一个实体的有效标识，就像日常生活中的身份证，可以唯一的标识一个实体，比如网站。而与证书相对应的“私钥”则是证明该实体是证书持有者的关键。在目前广泛部署的SSL/TLS协议中，网站通过传递自己的证书以及相对应的“私钥”签名信息，来向网络另一端的用户证明自己的真实性。因此私钥在网络的认证中具有极其重要的地位。换句话说任何形式的私钥窃取或者滥用，会导致网站被克隆，恶意的攻击者进而可以对访问的用户进行“钓鱼”。私钥的保护在互联网中是至关重要的，私钥对于一个提供互联网服务的公司来说属于其核心资产。

▌如何保护私钥？

为了保护私钥，现有的Web服务器都会提供私钥的加密服务，即私钥以文件形式持续化存储在硬盘上时是被加过密的。在服务启动阶段，通过输入对应的密码进行解密并加载到服务器的进程中去。这种比较初级的保护措施能达到的安全效果有限。在服务器进程加载了解密的私钥后，私钥会以明文的形式存在于系统内存中，任何可能导致内存信息被探测的软件或系统漏洞，如2014年爆发的OpenSSL心脏滴血漏洞，都可能造成私钥内容的泄露。

尤其是随着互联网规模的不断扩大，以前的单点服务模式已经无法满足互联网大量用户的请求。传统的CDN或者新的基于Cloud的CDN被大规模部署使用以提供高质量的互联网内容服务。CDN是通常由第三方服务商或者电信运营商提供的网络基础服务，这就意味着对CDN上内容的安全控制已经远远超出了网站运营者的控制，尤其是需要提供HTTPS服务的网站来说，如果想使用CDN对其内容进行缓存分发，必须要在CDN的服务节点上部署相应的私钥以满足终端用户接入HTTPS时的认证需求。正如前面所述，对私钥部署在外部CDN节点上安全的担忧一直是网站运营者的顾虑。

为了解决这一问题，不同的安全策略被各大CDN服务商提出。CDN服务商根据用户的需求提供的不同的私钥管理解决方案。第一种是私钥完全托管，即网站运营者将自己网站使用的私钥通过安全渠道发送给CDN服务商，由CDN服务商代其部署相应的HTTPS节点，当然这种做法是完全无法打消之前的安全的顾虑的。因此，CDN服务商还会提供另一种策略即共享证书，这种方式实际上相当于CDN服务商重新申请颁发一套新的证书，证书可以认证的实体包含了CDN服务商所支持的网站，私钥由CDN服务商持有。这种做法一定程度上缓解了网站运营者对自身私钥安全的担忧——因为使用的是CDN服务商共享证书的私钥而不是自己网站的私钥，但另一方面，对CDN服务商而言，如何保证共享证书的私钥的安全，同样也是一个难题。同时，这种共享证书的方式也增加了网站运营的管理负担以及需要承担的额外证书维护费用。

▌ Keyless SSL方案

2015年某CDN服务商提出了”Keyless SSL” [1] 方案。该方案在私钥安全性和网络性能之间做了一个折中， 引入了由网站运营者负责维护的“密钥中心”来保存密钥，对于CDN节点接受的每一个SSL请求，在CDN节点和密钥中心间引入一条新的安全连接用于请求相应的“私钥服务”。尽管通过SSL session reuse和长链接的形式可以减少一定的开销，但CDN节点和密钥中心额外的安全链接的引入不可避免的带来了网络延时的增加和吞吐率的下降。

图1. Keyless SSL 的建链流程 (RSA wrapping密钥交换)

图1 是Keyless SSL工作的典型流程，我们以TLS协议中最典型的RSA wrapping的密钥交换形式为例说明Keyless SSL是如何工作的。在这类密钥交换套件中，如图示第3步，客户端在验证了服务端证书的有效性之后，使用证书中的公钥对一个预主密钥（后续导出链接会话密钥的种子）进行加密。根据RSA算法的特性，只有对应的私钥才能正确解密出上述密文。当被加密的预主密钥到达CDN节点时，为了完成内容的检索和分发的请求，CDN必须使用正确的私钥对其进行解密来完成SSL的握手，这也是为什么CDN节点需要知道其托管网站的私钥。

Keyless SSL在这里引入了步骤4和5，在CDN节点不知道私钥的情况下，向后端的密钥中心（由真正的网站运营者管理）建立另一条安全连接，将需要被解密的报文转发给对应网站的密钥管理中心，在网站运营者自己管理的密钥中心里，预主密钥被相应的私钥正确解密并发还给CDN节点，CDN节点利用预主密钥即可完成SSL链接的建立。在整个过程中，网站私钥始终由自己的密钥中心管理，不必对外托管，CDN节点在不知道任何私钥信息的情况成功完成了SSL的建链，整个过程中保证了私钥的安全。

Keyless SSL在提高私钥安全性的同时也引入了更多的限制。首先，显而易见的对每一个客户端发起的SSL请求，都会增加一个CDN到后端密钥中心的交互，即增加了网络延迟，这与CDN就近访问原则相悖。另一方面，通过分布在全球各地的CDN节点，任何网站可以对不同地区的用户提供高质量的内容服务，然而后端密钥中心的引入，再次在分布式的网络中引入了一个中心节点，使得所有的安全连接的建立都要回溯到一个密钥中心，增加了网络瓶颈。

现实中的一些大型网站运营方，为了缓解汇聚来的大量的SSL/TLS建链请求，即SSL握手中CDN节点传送来的私钥服务请求，往往会使用硬件加速器，比如Intel® QAT，来卸载高CPU消耗的私钥运算。另一方面， 凭着硬件加速器在HTTPS服务中出色的性能加速效果，越来越多的网站和CDN服务商都开始标准化的部署硬件加速器，然而在Keyless SSL的方案中，CDN节点上部署的硬件加速器只能在数据传输阶段提供帮助，对于运算量最大的建链握手阶段却无法为客户的密钥中心分担压力，一定程度上造成了资源重复配置和浪费。

▌基于Intel® SGX 和 Intel® QAT的CDN密钥保护和HTTPS加速方案

为了彻底解决这一问题，Intel® QuickAssist Technology (QAT)[2]技术团队在2017年提出了一种针对CDN私钥保护的安全密钥管理和分发体系。该方案利用Intel® Software Guard Extensions (SGX) [3] 技术构建了安全的密钥分发和保护体系，使用了Intel® QAT硬件加速器在CDN节点上对SSL建链握手提供加速，摆脱了SSL请求中对后端密钥中心的依赖，充分利用CDN分布式的特性大大提高了网络性能。具体内容发表在2017年的ACM Symposium on Cloud Computing会议上[4].

图2. 结合Intel® SGX和Intel® QAT的CDN密钥保护和HTTPS加速方案

图2为我们展示了该方案的系统框图。CDN节点上部署了Intel® SGX和Intel® QAT加速器。在Phase 1阶段，密钥分发中心（KDC）将相应的私钥通过SGX的Remote Attestation 流程安全的部署到相应CDN节点的SGX enclave里面 （图中KSC中的KS）。Phase 2阶段KSC与Intel® QAT建立安全通道协商出用于保护私钥的会话密钥，并用此会话密钥将私钥加密导出至CDN服务器的硬盘上。Phase 3阶段，相应的Web service启动后，将硬盘中加密的私钥直接载入内存。在SSL建链阶段，所有需要私钥的操作均伴随着内存中加密的私钥卸载至Intel® QAT加速器中，QAT在硬件中完成私钥的解密和相应的运算并返回结果给上层的Web service以完成SSL握手。

 

整个过程中CDN对私钥的内容不可见。同时该方案中还包含撤销机制，当发现疑似有安全漏洞的CDN节点时，KDC可以撤销其相应的SGX enclave，保证私钥及时销毁并不再对其进行密钥部署。利用Intel® QAT对公钥算法良好的加速性能 [5] ，可以将单个CDN节点的SSL建链能力提升数倍，并且不需要每次向KDC请求私钥服务，消除了Keyless SSL网络中密钥中心的瓶颈同时提升了链接响应时间。

▌总结

该方案是Intel®安全技术和加速技术的典型结合，为CDN网络提供了安全保障的同时大幅提高HTTPS的处理性能。在Intel® QAT下一代的产品中引入了KPT（Key Protection Technology）技术，进一步提供了更加完善和便捷的密钥保护和加速方案，将在后续文章中详细介绍。

免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：niceseo99@gmail.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。