在本文中，我們將從網(wǎng)絡安全的四大核心屬性出發(fā)，逐步深入探討常見的威脅模型、強大的密碼學工具箱、保障信任的證書體系，并最終通過解析 TLS/HTTPS 協(xié)議，將所有知識點串聯(lián)起來。

奠定安全基石：網(wǎng)絡安全的四大核心屬性

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

• 機密性 (Confidentiality) ：確保信息只被授權的實體訪問和理解。通俗地說，就是“不該看的人看不懂”。即使攻擊者竊聽了你們的通信，他也無法解讀其中真正的內(nèi)容。實現(xiàn)機密性的主要技術是 加密 (Encryption) 。一個有趣的應用是機會性加密 (Opportunistic encryption)，它指的是即使通信雙方身份未經(jīng)嚴格認證，也進行加密，其主要目的是防止大規(guī)模、非針對性的網(wǎng)絡監(jiān)聽。
• 完整性 (Integrity) ：確保數(shù)據(jù)在傳輸或存儲過程中沒有被未經(jīng)授權地篡改或損壞。也就是說，你收到的數(shù)據(jù)必須和你朋友發(fā)送的數(shù)據(jù)一模一樣，一個比特都不能差。需要注意的是，加密本身只保證機密性，并不能防止攻擊者修改密文。在很多場景下，完整性的優(yōu)先級甚至高于機密性。
• 真實性 (Authenticity) ：確認通信參與方的身份是其所聲稱的身份。簡單來說，就是“確認和你聊天的是你以為的那個人”。真實性是建立安全通信的前提，你必須先確認對方的身份，然后才能放心地將機密信息發(fā)送給他。 證書 (Certificate) 是實現(xiàn)真實性的關鍵技術。
• 可用性 (Availability) ：確保授權用戶在需要時能夠正常訪問和使用網(wǎng)絡服務與資源。這個屬性主要用來對抗拒絕服務攻擊等旨在讓服務癱瘓的攻擊。

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

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

意外破壞 (Accidental Corruption)

這類威脅并非出于惡意，而是由硬件故障、軟件 bug、信道噪聲等原因?qū)е碌臄?shù)據(jù)損壞。我們熟悉的 IP 頭的校驗和、TCP/UDP 的校驗和以及以太網(wǎng)的幀校驗序列 (Frame Check Sequence, FCS)，其主要目的就是檢測這類意外錯誤。

對抗性攻擊 (Adversarial Attacks)

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

竊聽 (Eavesdropping)

攻擊者被動地監(jiān)聽網(wǎng)絡流量以獲取敏感信息。在早期的集線器 (Hub) 以太網(wǎng)或如今的 Wi-Fi 環(huán)境中，數(shù)據(jù)包以廣播形式發(fā)送，竊聽相對容易。在現(xiàn)代交換式網(wǎng)絡中，攻擊者可以通過 MAC 地址泛洪攻擊 (MAC Overflow Attack) ，向交換機發(fā)送大量偽造源 MAC 地址的數(shù)據(jù)包，耗盡其 MAC 地址表容量，迫使交換機進入“廣播模式”，從而監(jiān)聽到整個網(wǎng)絡的流量。

篡改 (Modification)

攻擊者在數(shù)據(jù)傳輸過程中主動修改、插入或刪除數(shù)據(jù)。例如，攻擊者可以修改數(shù)據(jù)包的目標地址，或者篡改 DNS 響應，將用戶引導至惡意網(wǎng)站。為了不被發(fā)現(xiàn)，攻擊者通常會重新計算并修改數(shù)據(jù)包的校驗和。對抗篡改的主要武器是 安全哈希 和 消息認證碼 (Message Authentication Code, MAC) 。

重放 (Replay)

攻擊者截獲一段合法的通信數(shù)據(jù)，然后在稍后的時間點重新發(fā)送它，以達到欺騙系統(tǒng)的目的。例如，截獲一個轉(zhuǎn)賬請求并重復發(fā)送。防御重放攻擊的一個有效方式是確保協(xié)議操作的 冪等性 (Idempotence) ，即重復執(zhí)行同一操作不會產(chǎn)生額外的副作用，或者在協(xié)議中加入時間戳或一次性隨機數(shù) (Nonce)。

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

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

ARP 欺騙 (ARP Spoofing) 是局域網(wǎng)中實現(xiàn) MITM 的常見手段。攻擊者通過偽造 ARP 響應，讓用戶的流量錯誤地發(fā)送到攻擊者的機器上，再由攻擊者轉(zhuǎn)發(fā)給真正的網(wǎng)關。

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

# ARP 欺騙后的通信 (Communication after ARP Spoofing)
# User A 的流量先被 Attacker 截獲，再由 Attacker 轉(zhuǎn)發(fā)
[ User A ] ----> [ Attacker ] ----> [ Gateway ] ----> [ Internet ]

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

DoS 攻擊及其分布式版本 DDoS，旨在通過消耗目標的網(wǎng)絡帶寬、計算資源或連接數(shù)，使其無法為正常用戶提供服務。DDoS 攻擊通常由一個控制端和大量被操控的“僵尸網(wǎng)絡 (Botnet)”構成。攻擊手段五花八門，遍布網(wǎng)絡協(xié)議的各個層級：

網(wǎng)絡層

• Ping 泛洪 (Ping Flood) ：用海量的 ICMP Echo Request 數(shù)據(jù)包淹沒目標。
• Smurf 攻擊 ：將偽造成受害者 IP 的 ICMP Echo Request 發(fā)送到一個網(wǎng)絡的廣播地址，導致該網(wǎng)絡所有設備都向受害者回復 IC-MP Echo Reply，形成流量放大效應。
• IP 碎片泛洪 (IP Fragment Flooding) ：發(fā)送大量 IP 碎片，但故意不發(fā)送最后一個碎片，迫使目標服務器為重組數(shù)據(jù)包而持續(xù)分配內(nèi)存，最終耗盡資源。

傳輸層

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

應用層

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

劫持 (Hijacking)

BGP 劫持 (BGP Hijacking) ：BGP 是互聯(lián)網(wǎng)的路由協(xié)議。攻擊者所在的自治系統(tǒng) (Autonomous System, AS) 可以惡意地向全球宣告一個不屬于它的 IP 地址段歸它所有，從而將原本流向這個 IP 段的流量“劫持”到自己的網(wǎng)絡中。2008 年巴基斯坦電信意外劫持 YouTube 流量就是一次著名的真實案例。

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

元數(shù)據(jù)隱私 (Metadata Privacy)

即使通信內(nèi)容被加密，數(shù)據(jù)包的 IP 頭部信息（如源/目標地址、數(shù)據(jù)包大小、通信時間）依然是明文的。這些元數(shù)據(jù)同樣可以暴露大量隱私信息。

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

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

安全哈希算法 (Secure Hash Algorithm)

哈希函數(shù)能將任意長度的輸入（消息）轉(zhuǎn)換成一個固定長度的輸出（哈希值或摘要）。一個安全的哈希函數(shù)應具備兩個關鍵特性：

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

哈希的主要用途是驗證 完整性 。SHA-256 和 SHA-3 是當前推薦使用的算法，而 MD5 和 SHA-1 已被證明存在嚴重安全缺陷，應避免使用。

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

MAC 也被稱為 帶密鑰的哈希 (keyed hash) 。它結合了一個秘密密鑰 K 和消息 M 來生成一個認證標簽 (tag)。接收方使用相同的密鑰和收到的消息重新計算標簽，并與收到的標簽對比。如果一致，就能證明消息在傳輸過程中 未被篡改 (完整性) ，并且該消息確實 來自持有相同密鑰的發(fā)送方 (真實性) 。HMAC 是一種基于哈希函數(shù)構造 MAC 的標準方法。

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

對稱加密 (Symmetric Encryption)

對稱加密使用同一個密鑰進行加密和解密。它的優(yōu)點是速度快，適合加密大量數(shù)據(jù)。

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

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

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

• 電子密碼本模式 (Electronic Code Book, ECB) ：這是最簡單但也最不安全的模式。它獨立地加密每個明文塊。如果明文中存在重復的塊，那么加密后的密文中也會出現(xiàn)重復的塊，從而暴露了原始數(shù)據(jù)的模式。 絕對不要使用 ECB 模式！
• 密文分組鏈接模式 (Cipher Block Chaining, CBC) ：為了解決 ECB 的問題，CBC 模式在加密當前明文塊之前，會先將其與前一個密文塊進行異或。這使得即使明文塊相同，產(chǎn)生的密文塊也不同，從而隱藏了數(shù)據(jù)模式。CBC 需要一個隨機且不可預測的 初始化向量 (Initialization Vector, IV) 作為第一個塊的“前一個密文塊”。

公鑰密碼學 (Public-key Cryptography)

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

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

RSA 是最著名的公鑰算法。相比對稱加密，公鑰加密的計算開銷非常大。因此，在實踐中，通常采用混合方案： 使用公鑰加密來安全地協(xié)商一個臨時的對稱密鑰，然后使用這個對稱密鑰進行高效的數(shù)據(jù)加密 。

密鑰交換與前向保密

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

一個極其重要的概念是 前向保密 (Forward Secrecy) 。它指的是，即使服務器的長期私鑰在未來某個時間點被泄露，攻擊者也無法用這個私鑰解密過去被截獲的通信數(shù)據(jù)。實現(xiàn)前向保密的關鍵在于每次會話都使用臨時的、用后即焚的密鑰（例如 Ephemeral Diffie-Hellman），而不是直接使用服務器的長期私KEY。

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

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

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

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

但注意兩點例外 / 限制：

1. 如果實現(xiàn)或配置錯誤（例如服務器同時記錄或泄露了 ephemeral 私鑰，或使用非臨時的 DH 參數(shù)），前向保密就失效。
2. 如果未來有算法/硬件（例如大規(guī)模量子計算機）能高效解決相應數(shù)學問題，那么現(xiàn)在記錄的握手也可能被解密 —— 這是為什么加密算法和參數(shù)需要周期性更新的原因。

TLS 1.3 默認使用基于（橢圓）DH 的 ephemeral 密鑰交換，天然優(yōu)先前向保密；而 TLS 1.2 只有在使用 ECDHE/DHE 時才有前向保密，使用 RSA 密鑰交換就沒有。

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

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

答案是 公鑰基礎設施 (Public Key Infrastructure, PKI) 和 數(shù)字證書 (Digital Certificate) 。

• 證書 ：一個由權威機構頒發(fā)的數(shù)字文件，它將一個身份（如域名 www.google.com）和一個公鑰綁定在一起。
• 證書頒發(fā)機構 (Certificate Authority, CA) ：一個受信任的第三方，負責驗證申請者的身份，并用自己的私鑰為申請者的證書進行簽名。
• 信任鏈 (Chain of Trust) ：你的操作系統(tǒng)和瀏覽器預裝了一批“根 CA”的證書。當你訪問一個網(wǎng)站（如 google.com）時，它會出示自己的證書。這個證書可能是由一個“中間 CA”頒發(fā)的，而這個中間 CA 的證書又是由根 CA 頒發(fā)的。通過逐級驗證簽名，你的瀏覽器最終可以確認 google.com 的證書是可信的，從而建立起一條信任鏈。

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

實戰(zhàn)剖析：TLS/HTTPS 如何保護你的通信

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

1. Client Hello ：客戶端向服務器發(fā)送它支持的 TLS 版本、一個密碼套件 (Cipher Suite) 列表和一個隨機數(shù) random_c。
2. Server Hello ：服務器從列表中選擇一個密碼套件，返回自己的證書和一個隨機數(shù) random_s。
3. 密鑰交換 ：客戶端驗證服務器證書。驗證通過后，生成一個 預主密鑰 (pre-master secret) ，用服務器證書中的公鑰加密后發(fā)送給服務器。
4. 生成會話密鑰 ：客戶端和服務器現(xiàn)在都擁有了 random_c、random_s 和 pre-master secret。它們使用這三個隨機源，通過一個偽隨機函數(shù) (PRF) 計算出完全相同的 主密鑰 (master secret) ，并由主密鑰進一步派生出會話所需的所有對稱密鑰（加密密鑰、MAC 密鑰等）。
5. Finished ：雙方各自發(fā)送一個 Finished 消息，該消息是之前所有握手消息的 MAC 值，并用剛剛生成的會話密鑰加密。這可以驗證整個握手過程沒有被篡改。

握手完成后，雙方就可以使用協(xié)商好的對稱會話密鑰來加密和認證應用數(shù)據(jù)了?，F(xiàn)代的 TLS (如 TLS 1.3) 還會優(yōu)先使用支持前向保密的密鑰交換算法 (如 ECDHE)。

下面是 TLS 1.3 握手協(xié)議的流程：

1. Client Hello （客戶端）：

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

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

這里的 0-RTT（zero-Round-Trip-Time） 是 TLS 1.3 的一項特性，允許客戶端在發(fā)出第一次網(wǎng)絡包（ClientHello）時就把應用數(shù)據(jù)一起發(fā)出去，無需等待服務器完成完整握手。換句話說：客戶端可以在“第 0 個往返”就發(fā)送數(shù)據(jù)，從而顯著降低延遲（對首包請求很有用）。

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

傳統(tǒng) HTTPS（HTTP/1.1、常見 HTTP/2 實現(xiàn)）：

1. DNS 解析 → 2. 與服務器建立 TCP 連接（例如到 443 端口）。
2. 在那個 TCP 連接上進行 TLS 握手 （協(xié)商協(xié)議版本、密碼套件、完成密鑰交換并建立加密通道）。
3. TLS 完成后， HTTP 請求/響應以加密形式在該通道上傳輸（HTTP 報文被 TLS 封裝和保護）。
4. TLS 握手期間可以通過 ALPN（Application-Layer Protocol Negotiation） 協(xié)商使用 HTTP/2、HTTP/1.1 等。

HTTP/3（QUIC）例外

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

其他補充

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

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

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

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