與暴露于互聯(lián)網(wǎng)的所有網(wǎng)絡一樣，CDN?必須防御在途攻擊、數(shù)據(jù)泄露，以及試圖通過 DDoS 攻擊壓垮目標源服務器的網(wǎng)絡的行為。CDN 可使用多種策略來緩解漏洞，包括適當?shù)?SSL/TLS 加密和專門的加密硬件。

什么是 SSL/TLS 加密？

傳輸層安全（TLS）是用于加密通過互聯(lián)網(wǎng)發(fā)送的數(shù)據(jù)的協(xié)議。TLS 源于安全套接字層（SSL）（首個被廣泛采用的 Web 加密協(xié)議），旨在是修復大多數(shù)早期協(xié)議的安全漏洞。出于歷史原因，業(yè)界仍然在某種程度上互換使用這兩個術語。如果您訪問 web 站點地址開頭為 https:// 而非 http://，那么該網(wǎng)站在瀏覽器和服務器之間進行的通信使用 TLS/SSL 加密。

為了防止攻擊者訪問重要數(shù)據(jù)，必須采取適當?shù)募用芊椒āＳ捎诨ヂ?lián)網(wǎng)的設計方式允許數(shù)據(jù)在許多位置之間傳輸，因此可以在含有重要信息的數(shù)據(jù)包在全球范圍內傳播時截獲它們。通過使用加密協(xié)議，只有預期的接收者才能夠解碼和讀取信息，防止中間人對所傳輸數(shù)據(jù)的內容進行解碼。

TLS 協(xié)議設計為提供 3 個組件：

身份驗證：驗證所提供身份標識的有效性

加密：模糊化從一臺主機發(fā)送到另一主機的信息

完整性：檢測偽造和篡改

什么是 SSL 證書？

要啟用 TLS，站點需要 SSL 證書和相應的密鑰。證書是包含有關站點所有者以及非對稱密鑰對中公鑰部分的信息的文件。證書頒發(fā)機構（CA）對證書進行數(shù)字簽名，以核實證書中的信息正確無誤。信任證書即表示，您信任證書頒發(fā)機構已進行了盡職調查。

操作系統(tǒng)和瀏覽器通常具有一份隱式信任的證書頒發(fā)機構名單。如果網(wǎng)站提供的證書是由不受信任的證書頒發(fā)機構簽名的，則瀏覽器會警告訪問者可能存在某種問題。

證書及其實施方式也可以根據(jù)強度、協(xié)議支持和其他特征進行獨立評級。隨著更新、更好的實施變得可用，或者其他因素導致認證實施的整體安全性降低，評級可能會不時變化。如果源服務器的 SSL 安全性實施比較舊且等級較低，那么其評級通常會比較差，而且容易受到破壞。

CDN 還有一個好處，使用 CDN 提供的證書可以為訪問其網(wǎng)絡內托管的資產(chǎn)的訪問者提供安全保護。因為訪問者僅連接到 CDN，所以源服務器和 CDN 之間使用較舊或較不安全的證書不會影響客戶端的體驗。

實際上，這種服務器至邊緣安全的薄弱仍然是一種漏洞，應予以避免，特別是考慮到有可能使用免費源加密輕松升級源服務器安全性的情況。

適當?shù)陌踩詫τ谟袡C搜索也很重要；加密的 Web 資產(chǎn)在 Google 搜索中的排名更高。

SSL/TLS 連接的運作不同于傳統(tǒng)的 TCP/IP 連接。在完成了 TCP 連接的初始階段后，就會發(fā)生單獨的交換以建立安全連接。本文把請求安全連接的設備稱為客戶端，并把提供安全連接的設備稱為服務器，就像用戶加載使用 SSL/TLS 加密的網(wǎng)頁時那樣。

首先，通過 3 個步驟進行TCP/IP 握手：

1.客戶端向服務器發(fā)送 SYN 數(shù)據(jù)包以發(fā)起連接。

2.服務器接著通過 SYN/ACK 數(shù)據(jù)包對著初始數(shù)據(jù)包做出響應，以便確認通信。

3.最后，客戶端返回 ACK 數(shù)據(jù)包以確認接到服務器發(fā)出的數(shù)據(jù)包。完成這一系列數(shù)據(jù)包發(fā)送和接收操作后，TCP 連接將處于打開狀態(tài)并且能夠發(fā)送和接收數(shù)據(jù)。

完成 TCP/IP 握手后，開始 TLS 加密握手。TLS 握手實施背后的詳細過程不在本指南的討論范疇。我們重點探討握手的核心目的，以及完成該過程所需的時間。

從高層次上講，TLS 握手包含三個主要組成部分：

客戶端與服務器協(xié)商 TLS 版本，以及通信中要使用的加密算法類型。

客戶端和服務器采取相應步驟，以確保彼此進行真實的通信。

交換密鑰，以用于以后的加密通信。

下圖呈現(xiàn)了 TCP/IP 握手和 TLS 握手中涉及的每個步驟。請注意，每個箭頭代表一個單獨的通信，該通信必須在客戶端和服務器之間進行物理傳輸。由于使用 TLS 加密時來回消息總數(shù)會增加，因此網(wǎng)頁加載時間也會增加。

出于說明目的，可以說 TCP 握手大約需要 50 毫秒，TLS 握手可能需要大約 110 毫秒。這主要是由于數(shù)據(jù)在客戶端和服務器之間雙向發(fā)送所花費的時間。往返時間 (RTT)的概念，即信息從一個設備傳輸?shù)搅硪粋€設備并返回所需的時間量，可用于量化創(chuàng)建連接的“昂貴”程度。如果不進行優(yōu)化并且不使用 CDN，額外的 RTT 代表最終用戶的延遲增加和加載時間減少。幸運的是，可以進行一些優(yōu)化來改善總加載時間并減少來回旅行的次數(shù)。

如何改善 SSL 延遲？

SSL 優(yōu)化可以減少 RTT 并縮短頁面加載時間。下方列出了可以優(yōu)化 TLS 連接的 3 種方式：

TLS 會話恢復：CDN 可以為其他請求恢復同一會話，使源服務器和 CDN 網(wǎng)絡之間的連接保持更長的時間。當客戶端需要進行未緩存的源獲取時，使連接保持活動狀態(tài)可以節(jié)省重新協(xié)商 CDN 與源服務器之間連接所花費的時間。只要源服務器在保持與 CDN 的連接的同時收到其他請求，該站點的其他訪問者就會體驗到較低的延遲。

會話恢復的總成本不到完整 TLS 握手的 50%，主要是因為會話恢復只需要一次往返，而完整的 TLS 握手需要兩次。此外，會話恢復不需要任何大的有限域算法（新會話需要），因此與完整的 TLS 握手相比，客戶端的 CPU 成本幾乎可以忽略不計。對于移動用戶而言，會話恢復帶來的性能提升意味著更具反應性和電池壽命友好的沖浪體驗。

啟用 TLS 虛假啟動：訪問者首次訪問網(wǎng)站時，上文所述的會話恢復將無濟于事。TLS 虛假啟動允許發(fā)送方無需進行完整的 TLS 握手，就能發(fā)送應用程序數(shù)據(jù)。

虛假啟動不會修改 TLS 協(xié)議本身，只會改變數(shù)據(jù)傳輸?shù)臅r間。一旦客戶端開始密鑰交換，加密確保會發(fā)生，數(shù)據(jù)傳輸就可開始。這一修改可減少往返總次數(shù)，將所需的延遲縮短 60 毫秒。

零往返時間恢復（0-RTT）：0-RTT 允許會話恢復，而且不增加連接的RTT 延遲。對于使用TLS 1.3和0-RTT 的恢復連接，連接速度得以改善，從而為用戶經(jīng)常訪問的網(wǎng)站帶來了更快速、更流暢的Web 體驗。這種速度提升在移動網(wǎng)絡上尤為顯著。

0-RTT 是有效的改進，但并非沒有安全上的妥協(xié)。為了應對所謂的重播攻擊的風險，CDN 服務可能會對 HTTP 請求的類型和允許的參數(shù)實施限制。要了解更多信息，請瀏覽 0-RTT 簡介。

CDN 防御 DDoS 攻擊

現(xiàn)代互聯(lián)網(wǎng)上 Web 資產(chǎn)最嚴重的安全漏洞之一是使用分布式拒絕服務 (DDoS) 攻擊。隨著時間的推移，DDoS 攻擊的規(guī)模和復雜性都在增加，攻擊者利用僵尸網(wǎng)絡攻擊具有攻擊流量的網(wǎng)站。大型且配置正確的 CDN 具有潛在的規(guī)模優(yōu)勢，可以作為 DDoS 的保護因素；通過擁有足夠的數(shù)據(jù)中心位置和相當大的帶寬能力，CDN 能夠承受和減輕大量傳入的攻擊流量，這些流量很容易使目標源服務器不堪重負。