CDN SSL/TLS | CDN 安全

缓解漏洞的 CDN 策略包括适当的 SSL/TLS 加密和专门的加密硬件。浏览 CDN 指南。

Share facebook icon linkedin icon twitter icon email icon

CDN 安全

学习目标

阅读本文后,您将能够:

  • 了解 CDN SSL/TLS 的工作方式
  • 探索针对 SSL/TLS 的 CDN 优化
  • 了解 CDN 如何改进过时的 SSL/TLS 证书
  • 了解 CDN 如何帮助缓解 DDoS 攻击

CDN 有哪些安全风险?

与暴露于 Internet 的所有网络一样,CDN 必须防御中间人攻击数据泄露,以及试图通过 DDoS 攻击压垮目标源站服务器的网络的行为。CDN 可以有多个策略用于缓解漏洞,包括适当的 SSL/TLS 加密和专门的加密硬件。

什么是 SSL/TLS 加密?

传输层安全(TLS)是用于加密通过 Internet 发送的数据的协议。TLS 源于安全套接字层(SSL)(首个被广泛采用的 Web 加密协议),目的是修复大多数早期协议的安全漏洞。出于历史原因,行业内仍然在某种程度上互换使用这两个术语。您访问的任何开头为 https:// 而非 http:// 的网站都将 TLS/SSL 用于浏览器和服务器之间进行的通信。


为了防止不良行为者访问重要数据,必须采取正确的加密方法。由于 Internet 的设计,数据可以在许多位置之间传输,因此可以在含有重要信息的数据包在全球范围内传播时截获它们。通过使用加密协议,只有预期的接收者才能够解码和读取信息,防止中间人对所传输数据的内容进行解码。

TLS 协议设计为提供 3 个组件:

  1. 身份验证:验证所提供身份标识的有效性
  2. 加密:混淆从一台主机发送到另一主机的信息
  3. 完整性:检测伪造和篡改

什么是 SSL 证书?

要启用 TLS,站点需要 SSL 证书和相应的密钥。证书是包含有关站点所有者以及非对称密钥对中公钥部分的文件。证书颁发机构(CA)对证书进行数字签名,以何时证书中的信息正确无误。通过信任证书,您信任证书颁发机构已进行了尽职调查。

SSL/TLS error graphic

操作系统和浏览器通常具有一份隐式信任的证书颁发机构名单。如果网站提供的证书是由不受信任的证书颁发机构签名的,则浏览器会警告访问者有问题在酝酿之中。


证书及其实施方式也可以根据强度、协议支持和其他特征进行独立评级。随着更新、更好的实施变得可用,或者其他因素导致认证实施的整体安全性降低,评级可能会不时变化。如果源站服务器的 SSL 安全性实施比较旧且等级较低,那么其评级通常会比较差,而且很容易受到破坏。


CDN 还有一个好处,使用 CDN 提供的证书可以为访问其网络内托管的资产的访问者提供安全保护。因为访问者仅连接到 CDN,所以源站服务器和 CDN 之间使用较旧或较不安全的证书不会影响客户端的体验。

SSL/TLS self-signed diagram

实际上,这种服务器至边缘安全的薄弱仍然代表着漏洞,应予以避免,特别是考虑到使用免费源站加密可以轻松升级源站服务器安全性的情况。

SSL/TLS self-signed diagram

适当的安全性对于自然搜索也很重要;加密的 Web 资产会可提高其在 Google 搜索中的排名。


SSL/TLS 连接的运作不同于传统的 TCP/IP 连接。在完成了 TCP 连接的初始阶段后,就会发生单独的交换以建立安全连接。本文把请求安全连接的设备称为客户端,并把提供安全连接的设备称为服务器,就像用户加载使用 SSL/TLS 加密的网页时那样。

首先,通过 3 个步骤进行TCP/IP 握手:

  1. 客户端向服务器发送 SYN 数据包以发起连接。
  2. 服务器接着通过 SYN/ACK 数据包对该初始数据包做出响应,以便确认通信。
  3. 最后,客户端返回 ACK 数据包以确认接到服务器发出的数据包。完成这一系列数据包发送和接收操作后,TCP 连接将处于打开状态并且能够发送和接收数据。
TCP 3-way handshake diagram

完成 TCP/IP 握手后,开始 TLS 加密握手。TLS 握手实施背后的详细过程不在本指南的讨论范畴。我们重点探讨握手的核心目的,以及完成该过程所需的时间。

从高层次上讲,TLS 握手包含三个主要组成部分:

  1. 客户端与服务器协商 TLS 版本,以及通信中要使用的加密密码的类型。
  2. 客户端和服务器采取相应步骤,以确保彼此进行真实的通信。
  3. 交换密钥,以用于以后的加密通信。

下图中视觉化呈现了 TCP/IP 握手和 TLS 握手中涉及的每个步骤。请注意,每个箭头代表一个单独的通信,该通信必须在客户端和服务器之间进行物理传输。由于使用 TLS 加密时来回消息总数会增加,因此网页加载时间也会增加。

SSL/TLS handshake diagram

为便于说明,假设 TCP 握手大约需要 50 毫秒,TLS 握手则可能大约需要 110 毫秒。这在大程度上是因为客户端和服务器之间双向发送数据所花费时间的结果。往返时间(RTT)是信息从一个设备传输到另一设备并再次返回所花费的时间,这个概念可用来量化连接的“昂贵”程度。如果未进行优化且未使用 CDN,则额外的 RTT 会增加延迟,并减少最终用户的加载时间。幸运的是,可以进行一些优化来缩短总体加载时间并减少来回行程的次数。

如何改善 SSL 延迟?

SSL 优化可以减少 RTT 并缩短页面加载时间。下方列出了可以优化 TLS 连接的 3 种方式:


TLS 会话恢复:CDN 可以为其他请求恢复同一会话,使源站服务器和 CDN 网络之间的连接保持更长的时间。当客户端需要进行未缓存的源站获取时,使连接保持活动状态可以节省重新协商 CDN 与源站服务器之间连接所花费的时间。只要源站服务器在保持与 CDN 的连接的同时收到其他请求,该站点的其他访问者就会体验到较低的延迟。

session resumption real time infographic

会话恢复的总成本不到完整 TLS 握手的 50%,主要是因为会话恢复仅花费一次往返,而完整 TLS 握手则需要两次往返。此外,会话恢复不需要任何大型有限域运算(新会话则需要),因此与完整 TLS 握手相比,客户端的 CPU 成本几乎可以忽略不计。对于移动用户而言,通过恢复会话来提高性能意味着可以获得反应更快、耗电更低的上网体验。

session resumption CPU time infographic

启用 TLS 错误启动:访问者首次访问网站时,上文所述的会话恢复将无济于事。TLS 错误启动允许发送方无需进行完整的 TLS 握手,就能发送应用程序数据。

SSL/TLS False Start handshake diagram

错误启动不会修改 TLS 协议本身,只会改变数据传输的时间。一旦客户端开始密钥交换,加密确保会发生,数据传输就可开始。这一修改可减少往返总次数,将所需的延迟缩短 60 毫秒。


零往返时间恢复(0-RTT):0-RTT 允许会话恢复,而且不增加连接的 RTT 延迟。对于使用 TLS 1.3 和 0-RTT 的恢复连接,连接速度得以改善,从而为用户经常访问的网站带来了更快速、更流畅的 Web 体验。这种速度提升在移动网络上尤为显著。


0-RTT 是有效的改进,但并非没有安全上的妥协。为了应对所谓的重播攻击的风险,CDN 服务可能会对 HTTP 请求的类型和允许的参数实施限制。要了解更多信息,请浏览 0-RTT 简介

CDN 防御 DDoS 攻击

现代 Internet 上 Web 资产的最严重安全漏洞之一是使用分布式拒绝服务(DDoS)攻击。随着时间的流逝,DDoS 攻击的规模和复杂性不断增加,攻击者利用僵尸网络攻击对网站发送流量攻击。正确配置的大型 CDN 具有规模效应的潜在优势,可以作为抵御 DDoS 的防护因素。拥有充足的数据中心位置和可观的带宽容量,CDN 能够承受和缓解能够轻松让目标源站服务器不堪重负的大量传入攻击流量。


还可以采取其他步骤来保护 TLS 连接。了解有关 Cloudflare CDN防御 TLS 攻击的更多信息。在 Cloudflare 诊断中心检查您的网站是否正确使用 HTTPS。