CDN SSL/TLS | CDN 安全

CDN 有哪些安全風險？

與暴露於網際網路的所有網路一樣，CDN 必須防禦在途攻擊、資料外洩，以及試圖透過 DDoS 攻擊壓垮目標原始伺服器的網路的行為。CDN 可以有多個策略用於緩解漏洞，包括適當的 SSL/TLS 加密和專門的加密硬體。

什麼是 SSL/TLS 加密？

傳輸層安全 (TLS) 是用於加密透過網際網路發送的資料的通訊協定。TLS 源於安全通訊端層 (SSL) (首個被廣泛採用的 Web 加密通訊協定)，目的是修復大多數早期通訊協定的安全漏洞。出於歷史原因，業界仍然在某種程度上互換使用這兩個術語。如果您訪問 web 網站位址開頭為 https:// 而非 http://，那麼該網站在瀏覽器和伺服器之間進行的通信使用 TLS/SSL 加密。

為了防止攻擊者存取重要資料，必須採取正確的加密方法。由於網際網路的設計，資料可以在許多位置之間傳輸，因此可以在含有重要資訊的封包在全球範圍內傳播時截獲它們。透過使用加密通訊協定，只有預期的接收者才能夠解碼和讀取資訊，防止中間人對所傳輸資料的內容進行解碼。

TLS 協定設計為提供 3 個元件：

1. 身分驗證：驗證所提供身分標識的有效性
2. 加密：模糊化從一台主機發送到另一主機的資訊
3. 完整性：偵測偽造和篡改

進一步瞭解 Cloudflare 的免費 SSL/TLS。

什麼是 SSL 憑證？

要啟用 TLS，網站需要 SSL 憑證和相應的金鑰。憑證是包含有關網站所有者以及非對稱金鑰對中公鑰部分的資訊的檔案。憑證頒發機構 (CA) 對憑證進行數位簽名，以核實憑證中的資訊正確無誤。信任憑證即表示，您信任憑證頒發機構已進行了盡職調查。

作業系統和瀏覽器通常具有一份隱含式信任的憑證頒發機構名單。如果網站提供的憑證是由不受信任的憑證頒發機構簽名的，則瀏覽器會警告訪客注意可能存在的問題。

憑證及其實作方式也可以根據強度、通訊協定支援和其他特性進行獨立評級。隨著更新、更好的實作開放使用，或者其他因素導致認證實作的整體安全性降低，評級可能會不時變化。如果原始伺服器的 SSL 安全性實作比較舊且等級較低，那麼其評級通常會比較差，而且很容易受到破壞。

CDN 還有一個好處，使用 CDN 提供的憑證可以為存取其網路內代管的資產的訪客提供安全保護。因為訪客僅連線到 CDN，所以原始伺服器和 CDN 之間使用較舊或較不安全的憑證不會影響用戶端的體驗。

實際上，這種伺服器至邊緣安全的薄弱仍然代表著漏洞，應予以避免，特別是考慮到使用免費原始加密可以輕鬆升級原始伺服器安全性的情況。

適當的安全性對於自然搜尋也很重要；加密的 Web 資產會可提高其在 Google 搜尋中的排名。

SSL/TLS 連線的運作不同於傳統的 TCP/IP 連線。在完成了 TCP 連線的初始階段後，就會發生單獨的交換以建立安全連線。本文把請求安全連線的裝置稱為用戶端，並把提供安全連線的裝置稱為伺服器，就像使用者載入使用 SSL/TLS 加密的網頁時那樣。

首先，透過 3 個步驟進行 TCP/IP 交握：

1. 用戶端向伺服器發送 SYN 封包以發起連線。
2. 然後，伺服器回應帶有一個 SYN/ACK 封包的初始連線，以便確認此通訊。
3. 最後，用戶端傳回 ACK 封包以確認收到來自該伺服器的封包。完成這個封包傳送和接收的序列後，TCP 連線將開啟並能傳送和接收資料。

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

總體而言，TLS 交握包含三個主要組成部分：

1. 用戶端與伺服器協商 TLS 版本，以及通訊中要使用的加密密碼的類型。
2. 用戶端和伺服器採取相應步驟，以確保彼此進行真實的通訊。
3. 交換金鑰，以用於以後的加密通訊。

下圖中直觀地呈現了 TCP/IP 交握和 TLS 交握中涉及的每個步驟。請注意，每個箭頭代表一個單獨的通訊，該通訊必須在用戶端和伺服器之間進行實體傳輸。由於使用 TLS 加密時來回訊息總數會增加，因此網頁載入時間也會增加。

為便於說明，我們假設 TCP 交握大約需要 50 毫秒，TLS 交握則可能大約需要 110 毫秒。主要因素是用戶端和伺服器之間雙向傳送資料所花費的時間。往返時間 (RTT) 是資訊從一個裝置傳輸到另一裝置並再次返回所花費的時間，這個概念可用來量化連線的「昂貴」程度。如果未進行最佳化且未使用 CDN，則額外的 RTT 會增加等待時間，並增加最終使用者的載入時間。幸好，有多種最佳化措施可用來縮短整體載入時間，並減少來回行程的次數。

如何改善 SSL 延遲？

SSL 最佳化可以減少 RTT 並縮短網頁載入時間。下方列出了可以最佳化 TLS 連線的 3 種方式：

TLS 工作階段恢復：CDN 可以為其他請求恢復同一工作階段，使原始伺服器和 CDN 網路之間的連線保持更長的時間。當用戶端需要進行未快取的原始獲取時，使連線保持活動狀態可以節省重新協商 CDN 與原始伺服器之間連線所花費的時間。只要原始伺服器在保持與 CDN 的連線的同時收到其他請求，該網站的其他訪客就會體驗到較低的延遲。

工作階段恢復的總成本不到完整 TLS 交握的 50%，主要是因為工作階段恢復僅需要一次往返，而完整 TLS 交握則需要兩次往返。此外，工作階段恢復不需要任何大型有限欄位運算 (新工作階段則需要)，因此與完整 TLS 交握相比，用戶端的 CPU 成本幾乎可以忽略不計。對於行動使用者而言，透過恢復工作階段來提高效能意味著可以獲得反應更快、耗電更低的上網體驗。

啟用 TLS 虛假啟動：訪問者首次訪問網站時，上文所述的會話恢復將無濟於事。TLS 錯誤啟動允許發送方無需進行完整的 TLS 交握，就能發送應用程式資料。

錯誤啟動不會修改 TLS 通訊協定本身，只會改變資料傳輸的時間。一旦用戶端開始金鑰交換，加密一定會發生，資料傳輸就可開始。這一修改可減少往返總次數，將所需的延遲縮短 60 毫秒。

零往返時間恢復 (0-RTT)：0-RTT 允許工作階段恢復，而且不增加連線的 RTT 延遲。對於使用 TLS 1.3 和 0-RTT 的恢復連線，連線速度得以改善，進而為使用者經常存取的網站帶來了更快速、更流暢的 Web 體驗。這種速度提升在行動網路上尤為顯著。

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

CDN 防禦 DDoS 攻擊

對現代網際網路上的 Web 資產而言，最重大的網路安全漏洞之一是分散式阻斷服務 (DDoS) 攻擊。隨著時間的流逝，DDoS 攻擊的規模和複雜性不斷增加，攻擊者會利用僵屍網路對目標網站發送攻擊流量。正確設定的大型 CDN 具有規模效應的潛在優勢，可以作為抵禦 DDoS 的防護因素。CDN 擁有充足的資料中心位置和可觀的頻寬容量，能夠承受和緩解大量傳入的攻擊流量，否則這些流量能夠輕鬆讓目標原始伺服器不堪重負。

還可以採取其他步驟來保護 TLS 連線。了解有關 Cloudflare CDN 和防禦 TLS 攻擊的更多資訊。在 Cloudflare 診斷中心檢查您的網站是否正確使用了 HTTPS。