SSL/TLS 與 IPSec 對比
文章目錄
- SSL/TLS 與 IPSec 對比
- 1. 前言
- 2. 握手階段上的差別
- 2.1 IPSec 握手流程
- 2.1.1 第一階段主模式協商流程
- 2.1.2 第二階段快速模式協商流程
- 2.2 SSL/TLS握手流程
- 2.2.1 基于ECDHE的握手流程
- 2.2.2 基于RSA的握手流程
- 2.3 ????IPSec與SSL/TLS的對比????
- 2.3.1 密鑰配送
- 2.3.2 協商流程
- 2.3.3 協商依賴的協定
- 2.3.4 保護對象
- 2.3.5 端認證
- 2.3.6 NAT相容性
面向人群：對IPSec和SSL/TLS比較熟悉的人員。
先說說此問題的由來吧????????????
在如今互聯互通的數字化資訊時代，資料安全越來越受重視。在網際網路中存在兩個非常相似的安全協定：一個為SSL/TLS協定；另一個為IPSec協定。盡管這兩個協定存在多種差别，但是從概念上講，這兩個協定有諸多相似的特性：
- 兩個都存在密鑰協商、握手階段和資料傳輸階段
- 都能提供機密性，完整性，源認證的功能
- 都是通過協商的方式來完整加密套件的協商
- 都支援做Virtual Private Network
此外應用場景又有很大的重疊。在許多地方都更可将IPsec 當成SSL。既可以用SSL 來保護任何在TCP 上傳輸的通信資料的安全，也可以使用IPsec 來保護任何IP 上運作的通信資料的安全，其中包括UDP應用。
基于以上種種，這就導緻人們剛開始無法知道他們的根本差別。當然還有另外一個原因：面試中的頻繁考點，經常讓我對比這兩個協定，我已經被問了好多次了，是以特地整理下這兩個的差別及其各自的特點。 然後從多個方面對這兩個協定做一個介紹，
| Ipsec | ssl | 說明 |
| 适用環境 | Site to Site | Client to Site |
| VPN層次 | IP 層 | 應用層 |
| 資料傳輸 | 隧道方式 | SSL傳輸 （TCP 443） |
| 用戶端 | 需專用軟體 | 無需專用用戶端軟體 |
| VPN部署 | 複雜 | 簡單 |
| 遠端維護管理 | 複雜，成本高 | 簡單，成本低 |
| 部署成本 | 高 | 低 |
| 移動連接配接 | 不适用 | 适用 |
| 加密級别 | ||
| 複雜應用支援 | 容易 | 較容易 |
| Intranet适用 | 較好 | 很好 |
| Web 應用 | 适合 | 非常适合 |
| 安全級别 | ||
| NAT支援 | 不容易 | |
| 代理通路 | ||
| 穿越防火牆 | ||
| 供應商互操作 | ||
| 即時消息傳送、多點傳播、視訊會議及VoIP | 較複雜 采用L3VPN | |
| B/S 應用 | 支援 | |
| Legacy application | ||
| http 應用 | ||
| 檔案共享 | ||
| Wireless device | ||
| 家庭、網吧、飯店、其他企業接入 | 不好 | 很好，非常适用 |
| 代理級保護 | 不支援 | |
| 使用者認證 | 好 | |
| 使用者授權 | 有限 | 靈活 |
| Web 通路一次性認證 | ||
| url 級别的接入限制 | ||
| 域名和IP位址的保護 | ||
| 根據使用者通路的類别控制接入 | ||
| Session 級保護 |
表中詳細列舉了IPSec和SSL/TLS協定的對比，下面對一些關鍵方面再做一個詳細的介紹。
目前，IPSec握手協定有兩個：IKEv1, IKEv2。IKEv2在協商流程上大大簡化，可以更加快速高效的建立連接配接。這裡主要通過IKEv1來介紹IPSec
如果想看不同模式下的IPSec協商封包格式（附帶密鑰，可以通過wireshark進行解密），
IKEv1協定中，IPSec握手流程分為兩個階段，共計三種模式。下面以主模式+快速模式共計9個封包互動介紹IPSec
兩個階段為：第一階段和第二階段。
第一階段有兩個模式：主模式和野蠻模式；
第二階段隻有一個模式：快速模式。
第一階段包含6個封包。用來兩端建立一條安全通道，在此安全通道的基礎上進行第二階段的協商。
- 第1,2個封包用來協商加密套件,包括加密算法，雜湊演算法，DH組，認證算法，密鑰長度，密鑰生存時間等；
- 第3,4個封包用來進行密鑰交換(DH算法進行密鑰交換)
- 第5,6個封包用來對雙方進行認證，對以前互動的封包做一個摘要計算。在此上下文前後完成三把密鑰的生成(加密密鑰，認證密鑰，衍生密鑰)
快速模式是在第一階段建立的安全通道基礎上進行的協商。此時協商封包已經被加密，是以互動是安全的。
第一階段協商的SA用來保護第二階段；
第二階段協商的SA是用于保護資料流通訊。 第二階段協商過程中通過ID載荷完成感興趣流的協商。
在IPSec中一個第一階段可以對應多個第二階段。在一條隧道已經給建立完畢的情況下，如果要想增加感興趣流，則隻需進行第二階段協商即可，無需再次進行完整協商。這在TLS中也是有相對應的流程！！！
SSL/TLS握手流程(以下簡稱為SSL握手流程)根據密鑰配送方式的不同，可以分為兩類：
- 基于ECDHE的握手流程
- 基于RSA的握手流程
如果使用DH算法進行密鑰交換，則協商流程中多了一個ServerKeyExchang載荷；如果使用RSA進行密鑰配送，則在用戶端使用伺服器證書中的公鑰進行密鑰，通過ClientKeyExchange載荷發送出去即可。
SSL握手流程沒有細分為多個階段，但是也需要多個封包交換才能完整SSL連接配接的建立。
都支援DH算法、基于證書RSA算法進行密鑰配送；除此之外IPSec還支援基于預共享密鑰的方式。
IPSec分為兩個階段：Phase I和Phase II。而SSL握手中不區分階段。
????????????那麼IPSec為什麼要區分兩個階段呢，而SSL卻不需要？????????????
這絕對是一個高頻考點！！！ 這個目前沒有看到标準答案，純屬自己了解，是以歡迎交流讨論
那麼IPSec為什麼要分為2個階段呢？
- 更加安全了。在加密的基礎上再次進行安全協商，是以會更加安全。就像現在很多檔案既提供MD5校驗又提供SHA1校驗，2份保障，加倍安全。但這個應該不是根本原因
-
可以實作快速協商。為什麼加了一個階段還可以實作快速協商呢？ 這是因為一個第一階段可以保護多個第二階段，第一階段隻有第一次建立隧道時可以直接複用第一階段，後續即使增加多個第二階段，也不需要再次協商第一階段(不考慮逾時情況)，而第二階段隻需要3個互動、2個往返時間，協商速度更快。而如果沒有第二階段，第一階段6個封包互動相對來說比較慢。我認為這個原因是最為重要的。在IKEv2中便不再區分第一階段第二階段，它的協商更加快速，這也與它優化了協商流程有關。在IKEv2中初次交換需要4個封包建立隧道，之後通過一次ChildSA交換便可以快速建立隧道。
而SSL協商的語義中有一個session複用的概念，如果用戶端想要複用一個存在的session, 會在ClientHello中将sessionID設定，服務端如果同意直接跳過握手階段，發送ChangeCipherSpec通知更換密鑰。SSL通過這種方式實作快速複用已經存在會話，是以沒有區分多個階段。
IPSec用來保護IP層安全，使用UDP協定進行協商；
SSL用來保護基于TCP協定的應用層安全，使用TCP協定進行協商
IPSec可以保護所有的IP封包，對于上層應用完全透明。如果要支援IPSec，應用層協定無需任何改動，相當的友好。
但是呢，雖然IPSec不需要修改應用層協定，但是需要修改作業系統。執行AH和ESP協定必須是IP棧的一部分，在大多數作業系統中，網絡協定棧位于作業系統核心中，是以安裝/激活IPSec就意味着安裝一個新的作業系統。不過值得一提的是目前主流的作業系統：windwos, linux都已經支援了IPSec。
而SSL/TLS無需修改作業系統，但是需要适配應用層協定。這麼多千奇百怪的應用層，這他麼的工作量可想而知，是以即使到目前為止SSL/TLS協定主要還是應用在HTTP、SMTP之上，很多其他應用協定沒有适配SSL/TLS。在實際應用中，由于大多數應用實際上都不需要安全。
反對 IPsec 的壓倒多數的理由就是需要對IP 棧進行改動。反對這種理由的理由是，為了保護應用的安全而無須對應用進行改動。
IPSec協商流程中，協商雙方強制互相認證，這樣是不友善的，因為在許多互動中，用戶端的身份都是不重要的。而SSL多數情況下隻認證服務端(用戶端認證可選)
看看IPSec普通的封包封裝，你就知道它與NAT相容性沒那麼好。NAT裝置一般根據封包4元組(IP, 端口)進行轉換，但是在IPSec的封包中AH\ESP頭部中根本沒有端口的概念，是以無法穿越NAT裝置。後來IPSec專門修改了在NAT下的封包封裝格式：在IP頭與AH/ESP頭部之間增加一個UDP頭部，專門用來做NAT轉換；NAT下不再使用IP位址作為辨別，改用其他參數作為辨別。通過這樣的封裝可以通過NAT裝置了，不過在IPSec協定棧中，增加了很多有關NAT的處理邏輯，導緻IPSec的實作更加複雜。
而SSL/TLS協定對NAT完全透明，因為它位于TCP協定之上，與NAT沒有半毛錢關系。是以SSL與NAT相容性非常友好。