5.2　傳輸安全

在介紹完網絡邊界安全之后，下面介紹網絡層傳輸安全。

5.2.1　VPN

虛擬專用網絡（Virtual Private Network，VPN）通過加密通信在公用網絡上建立專用網絡，使不同網絡區域之間的資源能夠跨過防火墻互訪，實現員工的企業遠程訪問和應用的云網互通等業務場景。VPN可通過服務器、硬件、軟件等多種方式實現，主要的通信協議主要有PPTP、L2TP和IPSec。其中，PPTP和L2TP協議工作在OSI模型的第二層（又稱為二層隧道協議），IPSec是第三層隧道協議。

1. IPSec（Internet Protocol Security）

1）IPSec VPN概述

（1）IPSec VPN是IP層也就是第三層VPN，封裝時IP頭為明文，IP頭之后是加密的密文。

（2）IPSec VPN可以實現源認證和不可否認性、完整性、私密性，以及防重放攻擊的功能。

（3）IPSec VPN數據封裝協議可以使用負載安全封裝協議（ESP）或認證頭協議（AH），也可以兩者共同使用。如果兩者共同使用建議ESP協議頭在里層，AH協議頭在外層。

（4）IPSec VPN可以實現私網與私網之間跨互聯網的安全通信。

2）IPSec VPN加密點與通信點

IPSec VPN加密點與通信點的描述如下，同時可以參考圖5-6來理解。

（1）通信點：實際通信實體。

（2）加密點：負責加密解密的設備。

3）IPSec VPN的工作模式

IPSec VPN的兩種工作模式如下。

（1）傳輸模式：IPSec VPN的可選模式。傳輸模式下加密包產生新的可路由IP頭，可解決不同私有網絡之間跨越互聯網的數據包加密傳輸問題，當加密點等于通信點時可以使用此模式，如GRE Over IPSec VPN可以選擇傳輸模式。

（2）隧道模式：IPSec VPN的默認模式。此模式下加密包不產生新的IP頭部，要求原IP包可在互聯網路由，要求通信點和加密點為同一IP，所有IPSec VPN都可以使用此模式。

IPSec的兩種工作模式如圖5-7所示。

在傳輸模式下，原始IP數據包在進行IPSec封裝時，會在原始IP頭與IP數據之間插入ESP協議頭。在隧道模式下，原始IP包將整個被加密，前面打上新的ESP頭部和新的IP頭部。所以通常在加密點等于通信點的情況下，建議將模式修改為傳輸模型，因為這樣可以節省一個IP頭的空間作為有效負載。

4）SA安全聯盟

（1）“安全聯盟”（IPSec術語，常簡稱為SA）是構成IPSec的基礎。SA是兩個通信實體經協商建立起來的一種協定。它們決定了用來保護數據包安全的IPSec協議、轉碼方式、密鑰及密鑰的有效期等。任何IPSec實施方案始終會構建一個SA數據庫（SADB），由它來維護IPSec協議用來保障數據包安全的SA記錄。

（2）SA是單向的。如果兩個主機（如A和B）正在通過ESP進行安全通信，那么主機A就需要一個SA，即SA（out），用來處理外發的數據包；另外，還需要一個不同的SA，即SA（in），用來處理進入的數據包。主機A的SA（out）和主機B的SA（in）將共享相同的加密參數（如密鑰），也就是說，主機A由什么策略加密出去，從主機B進來時就用什么策略解密。

（3）SA還是與“協議相關”的。每種協議都有一個SA。如果主機A和B同時通過AH和ESP進行安全通信，那么每個主機都會針對每種協議來構建一個獨立的SA。

（4）一般來說，如果只是用了ESP進行IPSec封裝，當一端加密點完成IPSec VPN協商以后，應該存在3個SA，一個Isakmp SA，兩個IPSec SA，其中一個ESP Out，一個ESP In。

5）SPD安全策略數據庫

關于SPD檢索的輸出，可能有下面幾種情況。

（1）丟棄這個包。此時包不會被處理，只是簡單地丟掉。（能夠在PC上采用）一般是無法向外轉發的包，如沒有路由的包。

（2）繞過安全服務。在這種情況下，IP層會在載荷內增添IP頭，然后分發IP包（也就是沒有被感興趣的流量匹配的包）。

（3）應用安全服務。（被感興趣流量匹配的包）在這種情況下，假如已建立了一個SA，就會返回指向這個SA的指針。假如尚未建立SA，就會調用IKE，將這個SA建立起來；如果SA已經建立，SPD內便會包含指向SA或SA集束的一個指針（具體由策略決定）。如果策略的輸出規定強行將IPSec應用于數據包，那么在SA正式建立之前，包是不會傳送出去的。這也是IPSec VPN的特性，數據包一旦被感興趣的流量匹配，要么加密轉發出去，要么沒有加密丟棄。

6）封裝安全負載協議（Encapsulation Security Payload，ESP）

（1）ESP的模式與包結構。

ESP主要包括兩種運行模型，即隧道模式和傳輸模式，這兩種模式的包結構分別如圖5-8和圖5-9所示。

① IP頭部：最外圍IP頭部是后加的加密點IP頭部。

② 安全標識（SPI）：是IPSec SA的ID和目標IP一起標示一個IPSec包，在出向封裝時，應用出向SPID，當入向檢查時應該檢查對端IP且檢查在本端的入向SPI中是否可以找到這個ID。如果可以找到，則認為合法，否則將會報告錯誤的SPI并丟棄這個包。例如，如果A和B建立了IPSec VPN，A有SA out和SA in，B有SA out和SA in，當A加密一個包發給B時，會將自己的SA out的ID寫在SPI這個位置上，當B收到這個包時，在自己的SA in里面尋找這個ID是否存在。

③ 序列號：也就是SN碼，可以用于防重放攻擊。當A加密一個數據包時，將IPSec進程的下一個序列號放在SN這個位置上，當B收到這個包時，檢查SN碼是否是期待的下一個ID，假如當前序列已經收到了100，而A發給B的SN碼還是100，那么這時B會認為是重放攻擊，將這個包丟棄。

④ 初始化向量（IV）：也就是初始化向量，也稱為CBC的加密種子，我們知道IPSec VPN使用了CBC（加密塊鏈接）的塊加密類型，IV是用于和第一個明文數據塊做異或的種子。

⑤ （內部的）IP頭部：原始數據包的IP頭也就是通信的IP頭。在隧道模式中被封裝在加密數據中。

⑥ TCP頭部：原始IP包上層協議。

⑦ 數據：原始數據包的數據部分，被封裝在加密數據中。

⑧ 填充物：由于IPSec VPN使用了塊加密類型，一個數據在進行切塊加密封裝時有可能尾部不足56比特，因此需要填充為56比特進行加密，而填充物部分就是填充的數據。

⑨ 填充物長度：用于描述尾部填充了多少比特。

⑩ 下一個頭：下一個頭協議，用于描述加密包經過解密后露出的最外面的頭協議，如在隧道模式下，如果將數據包解密，出現明文數據頭或IP包頭，那么這時的“下一個頭”就應該是4，表示IP in IP。

11 認證數據：用于容納Hash的驗證結果。

與隧道模式不同的是，傳輸模式少了一個IP頭部，而“下一個頭”部分在傳輸模式下，應該是解密后的明文數據頭，在這里明文數據頭解密后是TCP，也就是說這里的“下一個頭”應該是6；如果上層協議是UDP，那么“下一個頭”在這里就應該是17；如果上層協議是ICMP，那么這里就是1。

（2）關于ESP包的出向處理。

① 傳送模式：ESP頭緊跟在IP頭（包括IP頭可能有的任何選項）之后，插入一個出向的IP包中。IP頭的協議字段被復制到ESP頭的“下一個頭”字段中，ESP頭的其余字段則被填滿——SPI字段分配到的是來自SADB的用來對這個包進行出向處理的特定SA的SPI；填充序列號字段的是序列中的下一個值；填充數據會被插入，其值被分配；同時分配的還有填充長度值。隨后，IP頭的協議字段得到的是ESP的值或51。

② 通道模式：ESP頭是加在IP包前面的。一個IPv4包，ESP頭的“下一個頭”字段分配到值4；其他字段的填充方式和在傳送模式中一樣。隨后，在ESP頭的前面新增了一個IP頭，并對相應的字段進行填充（賦值）——源地址對應于應用ESP的設備本身；目標地址來自應用ESP的SA；協議設為51；其他字段的值則參照本地的IP處理加以填充。

③ 從恰當的SA中選擇加密器（加密算法），對包進行加密（從載荷數據的開頭，一直到“下一個頭”字段）。

④ 使用恰當的SA中的驗證器（Hash算法），對包進行驗證（自ESP頭開始，中間經過加密的密文，一直到ESP尾）。隨后，將驗證器的結果插入ESP尾的“驗證數據”字段中。

⑤ 重新計算位于ESP前面的IP頭的校驗和。

（3）關于ESP包的入向處理。

① 檢查收到包的SPID在本地入向SPI中是否存在。如果有就繼續處理；如果沒有就丟棄。

② 檢查序列號是否有效，并且檢查包大小是否小于我的Window Size。

③ 對數據包完整性和來源進行驗證，也就是對數據包進行Hash運算，并與Authentication Data部分抽出的Hash進行比對。如果比對成功就繼續處理；如果比對失敗就丟棄。

④ 對數據包解密（根據相關SA的策略選擇相應的密鑰和算法對包進行解密）。

⑤ 對數據包進行初步的有效性檢驗（如在L2L VPN中解密后流量需要再使用本地的感興趣流量列表反向檢查一遍）。

⑥ 驗證模式是否匹配。

⑦ 傳送模式：上層協議頭與IP頭是同步的，ESP頭的“下一個頭”字段被復制到IP頭的協議字段中，并計算出一個新的IP校驗和。

⑧ 通道模式：拋開外部IP頭和ESP頭，這里需要的是這個解開封裝的包。這時，必須進行另一個有效性檢驗。如果這個包和所要求的協議（SA）不相符，就必須將它丟棄。

⑨ 傳送模式：轉送到一個高一級的協議層，如TCP或UDP，由它們對這個包進行處理。

⑩ 通道模式包：重新插入IP處理流中，繼續轉發到它的最終目的地（也許在同一個主機上）。

2. PPTP

點對點隧道協議PPTP（Point to Point Tunneling Protocol）是實現VPN的方式之一，PPTP使用TCP創建控制通道來發送控制命令，并利用通用路由封裝GRE通道來封裝點對點協議PPP數據包以發送數據。

PPTP的協議規范本身并未描述加密或身份驗證的部分，它依靠PPP來實現這些安全性功能。因為PPTP協議內置在微軟視窗系統家族的各個產品中，在微軟點對點協議PPP協議堆棧中，提供了各種標準的身份驗證與加密機制來支持PPTP。在微軟視窗系統中，它可以搭配PAP、CHAP、MS-CHAPv1/v2或EAP-TLS來進行身份驗證。通常也可以搭配微軟點對點加密MPPE或IPSec的加密機制來提高安全性。

3. L2TP

L2TP（Layer Two Tunneling Protocol）是一種工業標準的互聯網隧道協議，功能大致與PPTP協議類似，如同樣可以對網絡數據流進行加密。不過也有不同之處，如PPTP要求網絡為IP網絡，L2TP要求面向數據包的點對點連接；PPTP使用單一隧道，L2TP使用多隧道；L2TP提供包頭壓縮、隧道驗證，而PPTP不支持這些功能。

L2TP通常用于VPN，L2TP協議自身不提供加密與可靠性驗證的功能，可以與加密協議搭配使用，從而實現數據的加密傳輸。經常與L2TP協議搭配的加密協議是IPSec，當這兩個協議搭配使用時，通常合稱L2TP/IPSec。

5.2.2　SSL

SSL（Secure Socket Layer）最早由Netscape發明，用以保障互聯網上數據傳輸的安全，利用數據加密技術，可確保數據在網絡上的傳輸過程中不會被截取及竊聽。SSL協議位于TCP/IP協議與各種應用層協議之間，為數據通信提供安全支持。SSL協議可分為兩層：SSL記錄協議（SSL Record Protocol）和SSL握手協議（SSL Handshake Protocol）。SSL記錄協議建立在可靠的傳輸協議（如TCP）之上，為高層協議提供數據封裝、壓縮、加密等基本功能的支持。SSL握手協議建立在SSL記錄協議之上，用于在實際的數據傳輸開始前，通信雙方進行身份認證、協商加密算法、交換加密密鑰等。

SSL的應用包括HTTPS（Hypertext Transfer Protocol Secure）安全超文本傳輸協議（可以說是HTTP的安全版），Extended Validation SSL Certificates擴展驗證EV SSL證書，以及各種網絡應用之間的數據傳輸。