SSL/TLS 与 IPSec 对比

SSL/TLS 与 IPSec 对比

1. 前言

面向人群：对IPSec和SSL/TLS比较熟悉的人员。

如果对这两个协议不太清楚，可以先补补基础知识，这里提供两个链接：

💥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协议的对比，下面对一些关键方面再做一个详细的介绍。

2. 握手阶段上的区别

2.1 IPSec 握手流程

目前，IPSec握手协议有两个：IKEv1, IKEv2。IKEv2在协商流程上大大简化，可以更加快速高效的建立连接。这里主要通过IKEv1来介绍IPSec

如果想看不同模式下的IPSec协商报文格式（附带密钥，可以通过wireshark进行解密），可以参考我曾经抓取的报文：

IPSec抓包.zip

IKEv1协议中，IPSec握手流程分为两个阶段，共计三种模式。下面以主模式+快速模式共计9个报文交互介绍IPSec

两个阶段为：第一阶段和第二阶段。

第一阶段有两个模式：主模式和野蛮模式；

第二阶段只有一个模式：快速模式。

2.1.1 第一阶段主模式协商流程

第一阶段包含6个报文。用来两端建立一条安全通道，在此安全通道的基础上进行第二阶段的协商。

• 第1,2个报文用来协商加密套件,包括加密算法，哈希算法，DH组，认证算法，密钥长度，密钥生存时间等；
• 第3,4个报文用来进行密钥交换(DH算法进行密钥交换)
• 第5,6个报文用来对双方进行认证，对以前交互的报文做一个摘要计算。在此上下文前后完成三把密钥的生成(加密密钥，认证密钥，衍生密钥)

2.1.2 第二阶段快速模式协商流程

快速模式是在第一阶段建立的安全通道基础上进行的协商。此时协商报文已经被加密，因此交互是安全的。

第一阶段协商的SA用来保护第二阶段；

第二阶段协商的SA是用于保护数据流通讯。 第二阶段协商过程中通过ID载荷完成感兴趣流的协商。

在IPSec中一个第一阶段可以对应多个第二阶段。在一条隧道已经给建立完毕的情况下，如果要想增加感兴趣流，则只需进行第二阶段协商即可，无需再次进行完整协商。这在TLS中也是有相对应的流程！！！

2.2 SSL/TLS握手流程

SSL/TLS握手流程(以下简称为SSL握手流程)根据密钥配送方式的不同，可以分为两类：

• 基于ECDHE的握手流程
• 基于RSA的握手流程

如果使用DH算法进行密钥交换，则协商流程中多了一个ServerKeyExchang载荷；如果使用RSA进行密钥配送，则在客户端使用服务器证书中的公钥进行密钥，通过ClientKeyExchange载荷发送出去即可。

SSL握手流程没有细分为多个阶段，但是也需要多个报文交换才能完整SSL连接的建立。

2.2.1 基于ECDHE的握手流程

详情可以参考：基于ECDHE的握手流程

2.2.2 基于RSA的握手流程

详情可以参考：基于RSA的握手流程

2.3 💖IPSec与SSL/TLS的对比💖

2.3.1 密钥配送

都支持DH算法、基于证书RSA算法进行密钥配送；除此之外IPSec还支持基于预共享密钥的方式。

2.3.2 协商流程

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通过这种方式实现快速复用已经存在会话，因此没有区分多个阶段。

2.3.3 协商依赖的协议

IPSec用来保护IP层安全，使用UDP协议进行协商；

SSL用来保护基于TCP协议的应用层安全，使用TCP协议进行协商

2.3.4 保护对象

IPSec可以保护所有的IP报文，对于上层应用完全透明。如果要支持IPSec，应用层协议无需任何改动，相当的友好。

但是呢，虽然IPSec不需要修改应用层协议，但是需要修改操作系统。执行AH和ESP协议必须是IP栈的一部分，在大多数操作系统中，网络协议栈位于操作系统内核中，因此安装/激活IPSec就意味着安装一个新的操作系统。不过值得一提的是目前主流的操作系统：windwos, linux都已经支持了IPSec。

而SSL/TLS无需修改操作系统，但是需要适配应用层协议。这么多千奇百怪的应用层，这他么的工作量可想而知，因此即使到目前为止SSL/TLS协议主要还是应用在HTTP、SMTP之上，很多其他应用协议没有适配SSL/TLS。在实际应用中，由于大多数应用实际上都不需要安全。

反对 IPsec 的压倒多数的理由就是需要对IP 栈进行改动。反对这种理由的理由是，为了保护应用的安全而无须对应用进行改动。

2.3.5 端认证

IPSec协商流程中，协商双方强制互相认证，这样是不方便的，因为在许多交互中，客户端的身份都是不重要的。而SSL多数情况下只认证服务端(客户端认证可选)

2.3.6 NAT兼容性

IPSec NAT穿越下的端口浮动

看看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兼容性非常友好。

根本原因还是在于这两个协议所在的层次不一致导致的。 天生如此，该认命吗？？？