当Https遇到Cdn：问题和挑战
虽然HTTPS提供服务器身份验证以及用户和网站2之间的安全通信，但CDN可实现高效的内容交付。两者都在当今的Web服务中发挥着重要作用。但是，我们发现这两种技术无法无缝协同工作。
图1描绘了一个概念性视图，说明采用CDN如何通过HTTPS显着改变安全的Web浏览。在图1a中，当用户通过HTTPS访问网站（Alice）时，用户的浏览器（Bob）首先向Alice打招呼，并在建立连接后接收Alice的证书。Bob然后高兴地认为对话是安全的，因为Alice的证书将连接与他的初始问候语联系起来。然而，在采用Carol提供的CDN服务时（图1b），该过程分为两个部分：在前端，Bob仍然以向Alice发出的问候消息开始对话，但最终连接到Carol; 在后端，假设采用基于拉取的策略，Carol需要在收到Bob的请求后从Alice获取内容。
图1。
使用cdn编写HTTPS的身份验证问题和解决方案的概念视图。
查看全部
在图1b的情况下，前端通信和后端通信都需要通过HTTPS进行证书身份验证保护，以确保在原始HTTPS通信中保证对被动窃听者和主动攻击者进行安全的Web浏览在图1a中。但是，这并不容易实现。
对于后端通信，Carol必须对Alice进行身份验证才能检测模拟攻击。相互身份验证虽然不是必需的，但也可以帮助Alice尽早拒绝未经请求的请求者。使用标准HTTPS实现这在技术上并不具有挑战性。然而，正如我们将在第四节中看到的那样，在目前的实践中并非总是如此。
前端通信的情况相当复杂，因为会话实际上涉及三方，因此身份验证不能通过标准HTTPS直接解决，标准HTTPS是两方协议（不考虑CA）。如图1b所示，如果Bob发送的初始消息和他收到的证书不匹配，Bob将向用户显示无效的证书警告，这会从用户的角度破坏HTTPS身份验证的有效性。
本质上，前端身份验证的问题是由Bob不知道Carol实际上被委托为代表Alice提供Web内容引起的。实际上，这个问题可以看作是分布式系统中的委托案例，这在以前的文献[7]，[8]中得到了推广。提出的解决方案的关键概念是类似的：委托令牌明确表示委托路径。但是，标准HTTPS无法直接表达此类委托令牌。因此，需要额外的努力来克服这个问题，如图1c所示。
以前的研究还提出了在各种威胁模型下设计委托令牌方案时的几个安全考虑因素。我们总结了一些符合以下三个要求的建议：
- 委托令牌必须是不可伪造的。这是抵制主动模仿攻击的基本要求。只有当委托令牌可以验证且防篡改时，目的地（在我们的例子中，Bob浏览器）才能在身份验证过程中信任它。
- 委托人应该能够独立有效地发布和撤销委托令牌。授权撤销的要求也是必不可少的。如果不保证撤销，攻击者仍然可以通过拦截和重放陈旧的委托令牌来进行冒充攻击。授权发布的要求来自运营效率。
- 委托令牌应包括委托人的完整标识。正如我们将在第IV节中进一步讨论的那样，在保证HTTPS证书的功能以显示适当的安全指示符时，这一要求也是必要的。
在以下部分中，我们将使用上述要求来检查现有机制的缺陷，并作为探索新解决方案的指南。