史丹佛CS144 電腦網路播客：網路安全關鍵概念與手段TLS/HTTPS

在本文中，我們將從網路安全的四大核心屬性出發，逐步深入探討常見的威脅模型、強大的密碼學工具箱、保障信任的憑證體系，並最終透過解析TLS/HTTPS 協議，將所有知識點串連起來。

奠定安全基石：網路安全的四大核心屬性

任何一個安全系統的設計，都離不開四個基本目標，它們是評估系統安全性的基石。

• 機密性(Confidentiality)  ：確保資訊只被授權的實體存取和理解。通俗地說，就是「不該看的人看不懂」。即使攻擊者竊聽了你們的通信，他也無法解讀其中真正的內容。實現機密性的主要技術是 加密(Encryption)  。一個有趣的應用是機會性加密(Opportunistic encryption)，它指的是即使通訊雙方身分未經嚴格認證，也進行加密，其主要目的是防止大規模、非針對性的網路監聽。
• 完整性(Integrity)  ：確保資料在傳輸或預存程序中沒有被未經授權地竄改或損壞。也就是說，你收到的資料必須跟你朋友發送的資料一模一樣，一個位元都不能差。要注意的是，加密本身只保證機密性，並不能防止攻擊者修改密文。在許多場景下，完整性的優先順序甚至高於機密性。
• 真實性(Authenticity)  ：確認通訊參與者的身分是其所聲稱的身分。簡單來說，就是「確認和你聊天的是你以為的那個人」。真實性是建立安全通訊的前提，你必須先確認對方的身份，然後才能放心地將機密資訊傳送給他。 憑證(Certificate) 是實現真實性的關鍵技術。
• 可用性(Availability)  ：確保授權使用者在需要時能夠正常存取和使用網路服務與資源。這個屬性主要用來對抗拒絕服務攻擊等旨在讓服務癱瘓的攻擊。

知己知彼：理解我們面臨的威脅

網路世界中的威脅多種多樣，我們可以將其大致分為兩類：意外破壞和蓄意的對抗性攻擊。

意外破壞(Accidental Corruption)

這類威脅並非出於惡意，而是由硬體故障、軟體 bug、通道雜訊等原因造成的資料損壞。我們熟悉的 IP 頭的校驗和、TCP/UDP 的校驗和以及乙太網路的幀校驗序列(Frame Check Sequence, FCS)，其主要目的就是檢測這類意外錯誤。

對抗性攻擊(Adversarial Attacks)

這是我們關注的重點，指攻擊者主動發起的、旨在破壞系統安全屬性的惡意行為。

竊聽(Eavesdropping)

攻擊者被動地監聽網路流量以獲取敏感資訊。在早期的集線器(Hub) 乙太網路或如今的Wi-Fi 環境中，資料包以廣播形式發送，竊聽也相對容易。在現代交換式網路中，攻擊者可以透過 MAC 位址泛洪攻擊(MAC Overflow Attack)  ，向交換器發送大量偽造來源 MAC 位址的封包，耗盡其 MAC 位址表容量，迫使交換器進入“廣播模式”，從而監聽到整個網路的流量。

篡改(Modification)

攻擊者在資料傳輸過程中主動修改、插入或刪除資料。例如，攻擊者可以修改封包的目標位址，或篡改 DNS 回應，將使用者引導至惡意網站。為了不被發現，攻擊者通常會重新計算並修改資料包的校驗和。對抗篡改的主要武器是 安全雜湊 和 訊息認證碼(Message Authentication Code, MAC)  。

重播(Replay)

攻擊者截獲一段合法的通訊數據，然後在稍後的時間點重新發送它，以達到欺騙系統的目的。例如，截獲一個轉帳請求並重複發送。防禦重播攻擊的一個有效方法是確保協定操作的 冪等性(Idempotence)  ，即重複執行相同操作不會產生額外的副作用，或在協定中加入時間戳或一次性隨機數(Nonce)。

中間人攻擊(Man-in-the-Middle, MITM)

這是最經典也最危險的攻擊之一。攻擊者將自己插入到兩個通信方之間，對雙方冒充對方的身份，從而能夠竊聽、篡改甚至完全控制雙方的通信，而通信雙方卻毫不知情。

ARP 欺騙(ARP Spoofing) 是區域網路中實現 MITM 的常見手段。攻擊者透過偽造 ARP 回應，讓使用者的流量錯誤地傳送到攻擊者的機器上，再由攻擊者轉送給真正的網關。

# 正常通信 (Normal Communication)
# User A 的流量直接发往 Gateway
[ User A ] ----> [ Gateway ] ----> [ Internet ]

# ARP 欺骗后的通信 (Communication after ARP Spoofing)
# User A 的流量先被 Attacker 截获，再由 Attacker 转发
[ User A ] ----> [ Attacker ] ----> [ Gateway ] ----> [ Internet ]
1.
2.
3.
4.
5.
6.
7.

拒絕服務攻擊(Denial of Service, DoS)

DoS 攻擊及其分散式版本 DDoS，旨在透過消耗目標的網路頻寬、運算資源或連線數，使其無法為正常用戶提供服務。DDoS 攻擊通常由一個控制端和大量被操控的「殭屍網路(Botnet)」所構成。攻擊手段五花八門，遍佈網路協定的各個層級：

網路層

• Ping 泛洪(Ping Flood)  ：用海量的 ICMP Echo Request 資料包淹沒目標。
• Smurf 攻擊 ：將偽造成受害者 IP 的 ICMP Echo Request 發送到一個網路的廣播位址，導致該網路所有裝置都向受害者回复 IC-MP Echo Reply，形成流量放大效應。
• IP 碎片泛洪(IP Fragment Flooding)  ：發送大量 IP 碎片，但故意不發送最後一個碎片，迫使目標伺服器為重組資料包而持續分配內存，最終耗盡資源。

傳輸層

• SYN 泛洪(SYN Flood)  ：利用 TCP 三次握手的缺陷，攻擊者發送大量偽造源 IP 的 SYN 包，伺服器為這些半開連接分配資源並等待 ACK，最終導致連接表被耗盡。

應用層

• DNS 放大攻擊(DNS Amplification Attack)  ：攻擊者偽造受害者 IP 向大量開放 DNS 解析器發送一個短請求，而 DNS 伺服器則會向受害者傳回一個非常大的回應，從而放大攻擊流量。
• SSL/TLS 握手攻擊 ：SSL/TLS 握手過程中，伺服器需要進行運算密集的公鑰解密操作。攻擊者透過發動大量握手請求來耗盡伺服器的 CPU 資源。

劫持(Hijacking)

BGP 劫持(BGP Hijacking)  ：BGP 是網際網路的路由協定。攻擊者所在的自治系統(Autonomous System, AS) 可以惡意地向全球宣告一個不屬於它的 IP 位址段歸它所有，從而將原本流向這個 IP 段的流量「劫持」到自己的網路中。 2008 年巴基斯坦電信意外劫持YouTube 流量就是一個著名的真實案例。

TCP 連線劫持(TCP Connection Hijacking)  ：攻擊者透過預測 TCP 序號(Sequence Number)，在兩個已建立連線的通訊方之間注入惡意數據，從而接管該 TCP 連線。

元資料隱私(Metadata Privacy)

即使通訊內容被加密，資料包的 IP 頭部資訊（如來源/目標位址、資料包大小、通訊時間）依然是明文的。這些元資料同樣可以暴露大量隱私資訊。

鑄造堅盾：密碼學的核心工具箱

密碼學(Cryptography) 是網路安全的數學基礎，它為我們提供了對抗上述威脅的強大武器。

安全哈希演算法(Secure Hash Algorithm)

雜湊函數能將任意長度的輸入（訊息）轉換成固定長度的輸出（雜湊值或摘要）。一個安全的雜湊函數應具備兩個關鍵特性：

1. 單向性(One-way)  ：從雜湊值反推出原始輸入在計算上是不可行的。
2. 抗碰撞性(Collision-resistant)  ：找出兩個不同的輸入，使得它們的雜湊值相同，在計算上是不可行的。

哈希的主要用途是驗證 完整性 。SHA-256 和 SHA-3 是目前建議使用的演算法，而 MD5 和 SHA-1 已被證明有嚴重安全缺陷，應避免使用。

訊息認證碼(Message Authentication Code, MAC)

MAC 也被稱為 帶有金鑰的哈希(keyed hash)  。它結合了一個秘密金鑰 K 和訊息 M 來產生一個認證標籤(tag)。接收方使用相同的金鑰和收到的訊息重新計算標籤，並與收到的標籤進行比較。如果一致，就能證明訊息在傳送過程中 未被竄改(完整性)  ，而該訊息確實 來自持有相同金鑰的傳送者(真實性)  。HMAC 是一種基於雜湊函數構造 MAC 的標準方法。

一個重要的實踐原則是 先加密，再認證(Encrypt-then-MAC)  ，也就是對加密後的密文計算 MAC 值。

對稱加密(Symmetric Encryption)

對稱加密使用同一個金鑰進行加密和解密。它的優點是速度快，適合加密大量資料。

一次性密碼本(One-Time Pad)  ：理論上最安全的加密方式。它使用一個與明文等長的、完全隨機的密鑰，與明文進行異或( XOR) 操作。它的安全性無懈可擊，但前提是金鑰必須是真隨機、只使用一次且安全地分發。這些嚴苛的條件使其在實務上幾乎無法應用。 密鑰重用是其致命缺陷 ，如果用同一密鑰加密兩個不同訊息 m1 和 m2，攻擊者可以透過 c1 XOR c2 直接得到 m1 XOR m2，從而破解密文。

流密碼(Stream Ciphers)  ：它模擬了一次性密碼本，透過一個種子金鑰產生一個足夠長的偽隨機金鑰流，然後與明文進行異或。早期的Wi-Fi 加密協定 WEP 就使用了流密碼，但因其設計缺陷而很快就被攻破。

分組密碼(Block Ciphers)  ：它將明文分成固定大小的區塊（如128 位元），然後對每個區塊進行加密。  AES (Advanced Encryption Standard) 是目前最受歡迎、最安全的分組密碼標準。為了加密比單一分組更長的訊息，需要配合不同的 工作模式(mode of operation)  。

• 電子密碼本模式(Electronic Code Book, ECB)  ：這是最簡單但也最不安全的模式。它獨立地加密每個明文區塊。如果明文中存在重複的區塊，那麼加密後的密文中也會出現重複的區塊，從而暴露了原始資料的模式。 絕對不要使用ECB 模式！
• 密文分組連結模式(Cipher Block Chaining, CBC)  ：為了解決 ECB 的問題，CBC 模式在加密目前明文區塊之前，會先將其與前一個密文區塊進行異或。這使得即使明文區塊相同，產生的密文區塊也不同，從而隱藏了資料模式。CBC 需要一個隨機且不可預測的 初始化向量(Initialization Vector, IV) 作為第一個區塊的「前一個密文區塊」。

公鑰密碼學(Public-key Cryptography)

公鑰密碼學，也稱非對稱加密，使用一對金鑰：一個 公鑰(public key) 和一個 私鑰(private key)  。公鑰可以公開分發，而私鑰必須由所有者嚴格保密。

• 加密通訊 ：任何人都可以用接收方的公鑰加密訊息，但只有持有對應私鑰的接收者才能解密。這完美地解決了對稱加密中金鑰分發的難題。
• 數位簽章(Digital Signature)  ：發送者可以用自己的私鑰對訊息的雜湊值進行“簽章”，接收者可以用發送方的公鑰來驗證簽章。如果驗證通過，就能確認訊息的 完整性 和 真實性 （即訊息確實由該私鑰擁有者發出且未被竄改）。

RSA 是最著名的公鑰演算法。相比對稱加密，公鑰加密的計算開銷非常大。因此，在實踐中，通常採用混合方案： 使用公鑰加密來安全地協商一個臨時的對稱金鑰，然後使用這個對稱金鑰進行高效的資料加密 。

密鑰交換與前向保密

Diffie-Hellman (迪菲-赫爾曼) 金鑰交換協定允許通訊雙方在一個完全公開的頻道上，協商出一個只有他們兩人知道的共享秘密，即使竊聽者監視了所有交換過程也無法得知這個秘密。

一個極為重要的概念是 前向保密(Forward Secrecy)  。它指的是，即使伺服器的長期私鑰在未來某個時間點被洩露，攻擊者也無法用這個私鑰解密過去被截獲的通訊資料。實現前向保密的關鍵在於每次會話都使用臨時的、用後即焚的密鑰（例如 Ephemeral Diffie-Hellman），而不是直接使用伺服器的長期私人KEY。

臨時金鑰並非「傳輸」私鑰本身，而是雙方各自產生臨時金鑰對並只交換臨時公鑰；透過（Ephemeral）Diffie–Hellman 的數學操作在雙方本地各自算出相同的共享金鑰。攻擊者即便事後拿到長期私鑰，也無法從握手中記錄的公鑰推算出當時的會話密鑰（前提是離散對數問題不可解）。

關鍵差異—RSA 金鑰交換vs. Ephemeral DH (DHE/ECDHE)

• 在傳統的RSA 金鑰交換（早期TLS 配置）中，客戶端產生 pre-master 並以伺服器的 長期公鑰 加密後傳送。若攻擊者事後取得伺服器的長期私鑰，就能解密錄下的握手記錄，從而恢復 pre-master 並解密過去會話－ 沒有前向保密 。
• 在 Ephemeral Diffie–Hellman (DHE/ECDHE) 中，客戶端和伺服器各自產生一次性的（ephemeral）DH 私鑰與對應公鑰，只交換 公鑰 。最終的會話金鑰= 基於雙方私鑰與對方公鑰在本地計算得到的共享值（例如 ），私鑰從未離開各自主機，也不會被明文發送。即使攻擊者後來拿到伺服器長期私鑰，也無法由握手記錄推出當時的ephemeral 私鑰或共享密鑰 ，因此過去會話保持保密—— 實現前向保密 。

數學/實現上的直覺 ：雙方交換的是 和 （公鑰），客戶端計算 ，伺服器計算 ，兩者相同。要從 或 推出 或 需要解決離散對數問題（被認為不可行）。

但注意兩點例外/ 限制：

1. 如果實作或設定錯誤（例如伺服器同時記錄或洩漏了ephemeral 私鑰，或使用非臨時的DH 參數），前向保密就失效。
2. 如果未來有演算法/硬體（例如大規模量子電腦）能高效解決相應數學問題，那麼現在記錄的握手也可能被解密—— 這就是為什麼加密演算法和參數需要周期性更新的原因。

TLS 1.3 預設使用基於（橢圓）DH 的ephemeral 金鑰交換，自然優先前向保密；而TLS 1.2 只有在使用ECDHE/DHE 時才有前向保密，使用RSA 金鑰交換就沒有。

信任的根基：憑證與公鑰基礎設施

公鑰密碼學很棒，但它留下一個關鍵問題：我如何確定這個公鑰真的屬於 Amazon，而不是某個中間人攻擊者偽造的？

答案是 公鑰基礎設施(Public Key Infrastructure, PKI) 和數 位憑證(Digital Certificate)  。

• 憑證 ：一個由權威機構頒發的數位文件，它將一個身分（如網域名稱 www.google.com）和一個公鑰綁在一起。
• 憑證授權單位(Certificate Authority, CA)  ：一個受信任的第三方，負責驗證申請者的身份，並用自己的私鑰為申請者的憑證進行簽署。
• 信任鏈(Chain of Trust)  ：你的作業系統和瀏覽器預先安裝了一批「根 CA」的憑證。當你造訪一個網站（如 google.com）時，它會出示自己的證書。這個證書可能是由一個「中間 CA」頒發的，而這個中間 CA 的證書又是由根 CA 頒發的。透過逐級驗證簽名，你的瀏覽器最終可以確認 google.com 的憑證是可信的，從而建立起信任鏈。

為防止 CA 被攻破或濫用權力， 憑證透明度日誌(Certificate Transparency Log) 機制被提了出來。它要求所有 CA 公開記錄其頒發的每一份證書，允許任何人監督，從而及時發現未經授權的證書。

實戰剖析：TLS/HTTPS 如何保護你的通信

 TLS ( Transport Layer Security  ) ，即傳輸層安全HTTPS協議，是 的核心。它位於 TCP 之上，應用層之下，為 HTTP 等應用層協定提供機密性、完整性和真實性保護。以下是 TLS 1.2 握手協定的簡化流程：

1. Client Hello  ：客戶端向伺服器發送它支援的 TLS 版本、一個密碼套件(Cipher Suite) 清單和一個隨機數字 random_c。
2. Server Hello  ：伺服器從清單中選擇一個密碼套件，傳回自己的憑證和一個隨機數 random_s。
3. 金鑰交換 ：客戶端驗證伺服器憑證。驗證通過後，產生一個 預主金鑰(pre-master secret)  ，用伺服器憑證中的公鑰加密後傳送給伺服器。
4. 產生會話金鑰 ：客戶端和伺服器現在都擁有了 random_c、random_s 和 pre-master secret。它們使用這三個隨機來源，透過一個偽隨機函數(PRF) 計算出完全相同的 主金鑰(master secret)  ，並由主金鑰進一步衍生出會話所需的所有對稱金鑰（加密金鑰、MAC 金鑰等）。
5. Finished  ：雙方各自發送一個 Finished 訊息，該訊息是之前所有握手訊息的 MAC 值，並用剛剛產生的會話金鑰加密。這可以驗證整個握手過程沒有被竄改。

握手完成後，雙方就可以使用協商好的對稱會話金鑰來加密和認證應用資料了。現代的 TLS (如 TLS 1.3) 也會優先使用支援前向保密的金鑰交換演算法(如 ECDHE)。

以下是 TLS 1.3 握手協定的流程：

1. Client Hello  （客戶端）：

• 包含支援的TLS 版本集合、密碼套件清單、key_share（客戶端的ephemeral 公鑰，如ECDHE 公鑰）、psk /  early_data（若嘗試0-RTT）、以及ALPN 等擴充。
• 客戶端計算並保存握手記錄的transcript（握手訊息哈希）。

2. （可能）  HelloRetryRequest  （伺服器）：如果伺服器需要客戶端使用其他曲線或金鑰交換參數，會傳回HelloRetryRequest，用戶端據此發送一個更新過 ClientHello（帶新的 key_share）。
3. ServerHello  （伺服器）：選擇版本、密碼套件並傳回自己的 key_share（伺服器ephemeral 公鑰）。到這一步，雙方都能基於各自的ephemeral 私鑰與對方公鑰匯出共享金鑰（ECDHE 產生的共享值）。
4. 派生握手金鑰（Handshake keys）  ：雙方使用HKDF 等機制基於共享值與早期secret（若有PSK）派生出“握手金鑰”，用於對後續握手訊息加密/認證。
5. EncryptedExtensions、Certificate、CertificateVerify、Finished（伺服器→客戶端）  ：伺服器在加密的握手通道上傳送其憑證（如果需要），並用 CertificateVerify 對憑證內容進行簽名，然後傳送 Finished。這些訊息已經由握手金鑰加密/認證，從而防止中間人篡改握手後半程。
6. 客戶端驗證並回應 ：客戶端驗證憑證鏈與 CertificateVerify，計算transcript hash，驗證伺服器的 Finished，然後發送（加密的）Finished 給伺服器。
7. 應用資料（Encrypted Application Data）  ：雙方以由master secret 衍生出的應用程式金鑰來加密後續的應用程式資料（HTTP 請求/回應）。
8. 會話恢復/ NewSessionTicket（可選，伺服器在握手後發送）  ：伺服器可在握手完成後發送 NewSessionTicket，客戶端以後用它+ PSK 做會話恢復或0-RTT 資料發送。

這裡的0-RTT（zero-Round-Trip-Time） 是TLS 1.3 的一個特性，允許客戶端在發出第一次網路套件（ClientHello）時就把應用資料一起發出去，無需等待伺服器完成完整握手。換句話說：客戶端可以在「第0 個往返」就發送數據，從而顯著降低延遲（對首包請求很有用）。

HTTPS 基本流程就是這樣：應用（HTTP）在TLS 之上，TLS 在傳輸層（通常是TCP）之上。常見HTTPS 流程為：建立TCP → 在該TCP 上做TLS 握手→ 握手完成後在加密頻道上傳送HTTP。但也有現代變體（例如QUIC/HTTP/3）把TLS 與傳輸層更緊密地結合了。

傳統HTTPS（HTTP/1.1、常見HTTP/2 實作）：

1. DNS 解析→ 2. 與伺服器建立 TCP 連線（例如到443 連接埠）。
2. 在那個TCP 連線上進行 TLS 握手 （協商協定版本、密碼套件、完成金鑰交換並建立加密通道）。
3. TLS 完成後，  HTTP 請求/回應以加密形式在該通道上傳輸（HTTP 封包被TLS 封裝和保護）。
4. TLS 握手期間可透過 ALPN（Application-Layer Protocol Negotiation） 協商使用HTTP/2、HTTP/1.1 等。

HTTP/3（QUIC）例外

• QUIC 是基於UDP 的新傳輸協議，它將運輸層功能和TLS 安全性整合在同一個協定中。也就是說，QUIC 在握手過程中同時完成傳輸層建立和TLS 安全協商（TLS 1.3 的握手被嵌入QUIC），因此沒有先TCP 再TLS 再HTTP 的嚴格分層：是UDP → QUIC（內含TLS）→ HTTP/3。這樣可以減少連線建立延遲和提升遷移/重連效能。

其他補充

• TLS 會話復原/ PSK  ：為了降低延遲，用戶端可使用會話復原或預共用金鑰（PSK）來跳過完整握手，從而減少RTT。 TLS 1.3 在這方面更有效率（0-RTT 有風險：早期資料在重播和部分安全屬性上要謹慎）。
• TLS 本身不是專門為HTTP 設計的，它可以保護多種應用層協定（SMTP、IMAP、資料庫協定等），但HTTPS 是其最常見的應用場景。

安全之道：超越演算法的設計哲學

一些超越具體技術的高層次安全原則如下。

• 不要自己發明或實作加密演算法(Don't roll your own crypto)  ：密碼學極為微妙，一個微小的實作錯誤都可能導致整個系統崩潰。永遠優先使用經過公開、嚴格審查的、被廣泛接受的標準庫和實作。
• 保持加密敏捷性(Crypto Agility)  ：在設計系統時，應使其能夠方便地切換和升級加密演算法。當某個演算法被發現不再安全時，你可以迅速遷移到更強的替代方案。
• 培養安全思維(Security Mindset)  ：始終以攻擊者的視角來審視自己設計的系統。遵循 縱深防禦(Defense in Depth) 和 最小權限原則(Least Privilege)  ，假設任何組件都可能被攻破，並為此設計應對措施。
• 假定網路是不安全的(Assume the network is insecure)  ：這是網路安全設計的黃金法則。永遠不要信任底層的網路。你應該假設攻擊者可以竊聽、篡改、重播、劫持你的所有網路通信，並在此基礎上建立你的安全協議。